Review Request: Allow StatusNotifierItem DBus objects to register with the StatusNotifierWatcher without creating a specific DBus service
Aurélien Gâteau
agateau at kde.org
Wed Apr 14 15:56:59 CEST 2010
> 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.
>
> Marco Martin wrote:
> 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.
I just added it to the test program, it works correctly.
This patch only affects kdebase, not kdeui. The only situation where this could break is if the user is running an old version of the StatusNotifierWatcher kded module with the latest version of the StatusNotifierItem dataengine or vice/versa. I don't think this is going to happen.
- Aurélien
-----------------------------------------------------------
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
>
>
More information about the Plasma-devel
mailing list