> 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 > > _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
