Review Request: Allow StatusNotifierItem DBus objects to register with the StatusNotifierWatcher without creating a specific DBus service

[Marco Martin]

> On 2010-04-13 16:26:55, Marco Martin wrote:
> > have you tested with an application registering two items?
> > i would like keeping this possibility required in the specification and kmix needs it
> 
> Aurélien Gâteau wrote:
>     No I haven't. I think it should still work though, since RegisterStatusNotifierItem() can still be called with the full service name (including $N).
>     
>     Do you know of an existing application which register two items? If not I'll extend kstatusnotifieritemtest to test it.

adding it to the test would be nice.
iirc kmix uses two for a fraction of second when changing settings.

another problem i see is retrocompatibility:
old applications should work just fine on a newer kde, i don't think the other way around tough (is a plausible scenario having kdeui and the workspace in different versions?).
If this won't be considered a problem, i'm fine with the change, just update the spec accordingly.


- Marco


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/3587/#review5010
-----------------------------------------------------------


On 2010-04-13 14:25:42, Aurélien Gâteau wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/3587/
> -----------------------------------------------------------
> 
> (Updated 2010-04-13 14:25:42)
> 
> 
> Review request for Plasma and Marco Martin.
> 
> 
> Summary
> -------
> 
> The current StatusNotifierItem spec (SNI) requires applications to create a separate DBus service with a special name (org.kde.StatusNotifierItem-$PID-$N) and a special object path (/StatusNotifierItem). This patch removes this limitation, making it possible for applications to expose an object implementing the SNI interface on their main DBus service. In other words, instead of requiring this:
> 
> - :1.234                             /MyApp/AnObject
>                                      /MyApp/AnotherObject
> - org.kde.StatusNotifierItem-$PID-$N /StatusNotifierItem <- object implementing SNI interface
> 
> It is possible to also have this:
> 
> - :1.567 /AnotherApp/AnObject
>          /AnotherApp/AnotherObject
>          /AnotherApp/SNI <- object implementing SNI interface
> 
> This works by making the code implementing RegisterStatusNotifierItem(id) a bit smarter.
> 
> It now can be called either like this: RegisterStatusNotifierItem("org.kde.StatusNotifierItem-$PID-$N"), in which case it uses the SNI object at "org.kde.StatusNotifierItem-$PID-$N/StatusNotifierItem".
> 
> Or like this: RegisterStatusNotifierItem("/AnotherApp/SNI"), in which case it looks for the service name of the sender (:1.567) and uses the SNI object at ":1.567/AnotherApp/SNI".
> 
> 
> Diffs
> -----
> 
>   trunk/KDE/kdebase/workspace/plasma/generic/dataengines/statusnotifieritem/statusnotifieritemsource.cpp 1114328 
>   trunk/KDE/kdebase/workspace/statusnotifierwatcher/statusnotifierwatcher.h 1114328 
>   trunk/KDE/kdebase/workspace/statusnotifierwatcher/statusnotifierwatcher.cpp 1114328 
> 
> Diff: http://reviewboard.kde.org/r/3587/diff
> 
> 
> Testing
> -------
> 
> In Ubuntu Lucid, GNOME applications expose SNI objects by reusing the main service, while KDE applications expose them using a separate service. This has been tested and confirmed to work well for all combinations of KDE / GNOME applications and KDE / GNOME desktops.
> 
> 
> Thanks,
> 
> Aurélien
> 
>