Hi, On Mon, 27 Apr 2015 20:28:22 +0300, Alberts Muktupāvels wrote:
I have started to write library for this, but... There are already few things I dislike about this spec: 1. I don't get why spec use /StatusNotifierItem as dbus path not /org/freedesktop/StatusNotifierItem. Don't know if there are some recommended way or something like that, but mostly I see second version. If I would write library without looking at other libraries I would use second path and that would make library incompatible with existing items. I did not see anything about this in documentation/specification.
Is there really any problem with using just /StatusNotifierItem? I think other implementations have no problem with that.
2. Spec should be called StatusNotifier not StatusNotifierItem. StatusNotifier has three items - StatusNotifierItem, StatusNotifierWatcher and StatusNotifierHost so i think spec should be just StatusNotifier.
Yeah. I think at the early stages of this spec there was only StatusNotifierItem, thus this naming.
3. Specification does not include any info about protocol version... I have no idea what should be put there.
Nice catch.
4. Method/signal names probably could not be larger. Why the RegisterStatusNotifierItem, RegisterStatusNotifierHost. They could be simply RegisterItem, ReghisterHost.
Agreed. But again, I think compatibility is more important.
5. There is signal for registered and unregistered items. But for host there is only registered signal. We need to know when hosts disappears. what I am supposed to do? emit registered signal (when host actually disappears) so item can then read IsStatusNotifierHostRegistered property to know that there is no hosts anymore so it should fallback to old try icon? I think it would make sense that there is unregistered signal for host too.
You can check when an object disappears from the bus, though it will be a bit ugly. The spec is evolving AFAICS (i.e. name changed from org.kde to org.freedesktop), so I think there are chances to change it. I think we can contact David Edmundson from KDE about this. Should I forward your mail to him?
Then if we speak about Canonical indicators. There is watcher, but it does not emit signals when new items are registered or unregistered - I was thinking about watching org.kde.StatusNotifierWatcher so we can display items that are registered with it, but it just did not work. I have already app that works as watcher, still need to write host and item parts...
Canonical's indicators have two "levels": there is an indicator API that is a private one and is used by a limited set of indicators (examples are indicator-power, indicator-sound and indicator-application), and the appindicator API that applications should use (all appindicators are handled by indicator-application). The appindicator API allows the app to set an icon and a menu on it, nothing else. Indicator-application supports StatusNotifierItem's, but with some limitations. First, the SNI should have its menu exported using DBusMenu (that is Canonical's protocol, and has little to do with GLib's menu protocol). That differs from the SNI spec, which expects the menu to be handled client-side. Second, the icon should be provided by an icon theme, not passed via D-Bus. So basically Canonical indicators are a subset of SNI's from the applications point of view. I don't think we should consider them. -- Dmitry Shachnev
Attachment:
signature.asc
Description: OpenPGP digital signature