[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: Review Request: Allow StatusNotifierItem DBus objects to register
From:       Aurélien Gâteau <agateau () kde ! org>
Date:       2010-04-19 15:17:21
Message-ID: 20100419151721.26898.61787 () localhost
[Download RAW message or body]



> On 2010-04-14 14:28:50, Marco Martin wrote:
> > ok, go for it.
> > don't forget to add in the spec at least a recomendation on how the naming should \
> > be done
> 
> Aurélien Gâteau wrote:
> Committed. On my way to update the spec.

While updating the spec I realized it was a bit odd to provide two different ways to \
register StatusNotifierItems. Is there a particular reason for using a separate DBus \
service instead of exposing SNI objects on the application main service? Since one \
has to register with the watcher in both cases, I don't see the need for a separate \
service.

If there is no need for this separate service, I suggest switching to exposing SNI on \
the application service, as it is more DBus-like. We could expose them under \
/org/kde/StatusNotifierItem/$N to support multiple instances. If you agree I can work \
on a patch to do this.


- Aurélien


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


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


[prev in list] [next in list] [prev in thread] [next in thread]