dbusmenu-list team mailing list archive

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

Marco Martin wrote:
> On Monday 04 January 2010, Aurélien Gâteau wrote:
>> Hi,
>>
>> As you (probably) know, Qt provides a way for menus to be populated on
>> the fly: when a menu is about to be displayed, QMenu emits the
>> aboutToShow() signal. Any slot connected to this signal can manipulate
>> the menu content before it actually gets shown.
>>
>> We need a way to implement this in dbusmenu without introducing latency.
>> Here is my proposal for this:
>>
>> Add a "bool aboutToShow(id)" method to the DBus interface. This method
>> would be called when the menu is about to show and should return true if
>> the menu needs to be refreshed, false otherwise.
>>
>> The calling sequence would be as described in attached diagram.
>>
>> In the most common case (no update), this solution only introduces at
>> worst a 10 msecs delay (in case the DBus answer to aboutToShow() does
>> not come back before the timeout).
>>
>> I am just wondering whether it would make sense to receive the updated
>> items as an out argument in aboutToShow(). Ie, aboutToShow() could have
>> this signature:
>>
>> bool
>> aboutToShow(/* in */  uint id,
>>             /* in */  array<string> propertyNames,
>>             /* out */ DBusMenuItemList* menuItems)
>>
>> (The menuItems argument would only be used if aboutToShow returns true)
>> This would avoid a separate DBus call in the Refresh state.
>>
>> What do you think about this?
> 
> the latter way is perhaps less pretty (using a signal for aboutToshow() would 
> make a nice 1-1 correspondence) but it should significantly reduce round-trips 
> and that's the main thing we should look about in DBus interfaces.

As far as I know, using a signal won't really make a nice 1-1
correspondence unless the signal is synchronous, which is not the case
with DBus.

I agree it would reduce round trips though, I will probably give it a try.

> 
> it should be an async call anyways, so the "wait 10 msec and then go ahead 
> anyways" rule should be applied in this case too, i wonder what shouls happen 
> in this scenario:
> 
> the menu visualization calls aboutToshow, waits 10 msec nothing back shows the 
> menu
> but the app was just really busy and cpuldn't answer, but it has a new menu 
> anyways
> the host shows the old menu, maybe with entries not valid anymore
> the user clicks an invalid entry...

In the current implementation, nothing should happen because the code
won't find an action associated with the id of the menu item (we do not
reuse ids).
> 
> perhaps the host should change on the fly the menu when the answer arrives 
> even if there was a timeout and the menu is already displayed...

That's an option, but I am wondering whether it's worth the price: it
would make the menu code significantly more complex for what I believe
should be a rare corner-case. In any case, this can be implemented
later: the implementation is free to ignore or take into account a late
answer.

Aurélien