dbusmenu-list team mailing list archive

[Aurélien Gâteau <aurelien.gateau@xxxxxxxxxxxxx>]

Ted Gould wrote:
> On Fri, 2010-01-22 at 18:16 +0100, Aurélien Gâteau wrote:
>> Ted Gould wrote:
>>> On Fri, 2010-01-22 at 10:12 +0100, Aurélien Gâteau wrote:
>>>> Ted Gould wrote:
>>>>> On Tue, 2010-01-12 at 10:13 +0100, Aurélien Gâteau wrote:
>>>>>> Since we introduce a new method, getting the result from the return
>>>>>> value rather than waiting for a signal feel more efficient.
>>>>> But, if we implemented the event mask that we had discussed (I don't
>>>>> think anyone has implemented it) then we would know whether a menu was
>>>>> interested in the event and we should wait.
>>>> I can't remember this event mask discussion. Care to refresh my fading
>>>> memory?
>>> The idea was that we could have a property for individual items so that
>>> we would know what event it was interested in.  The idea was to not send
>>> dbus traffic when we didn't need it.  That way we would send
>>> "AboutToShow" in this case if the menu didn't care.
>> This is a good idea, but unfortunately there is no way (that I know of)
>> in Qt to know whether there are slots connected to a signal, meaning no
>> way for KStatusNotifierItem to know whether the app actually plans to
>> update the menu when it is about to show.
> 
> Yes, but I think we should have it so that we can optimize this as we
> go.  I think it's an optimization we'll need,

My "premature optimization" warning just turned on as I read this.

> perhaps we can convince
> Nokia to allow us to know when the slot is registered for at some point.
> It seems rather silly that you can't query a signal.

Good luck with this.

Anyway, feel free to add this. The Qt implementation will just
unconditionally request all events.

Aurélien