Re: [gnome-flashback] Future of the system tray

[Alberts Muktupāvels <alberts muktupavels gmail com>]

Hi,

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.

2. Spec should be called StatusNotifier not StatusNotifierItem. StatusNotifier has three items - StatusNotifierItem, StatusNotifierWatcher and StatusNotifierHost so i think spec should be just StatusNotifier.

3. Specification does not include any info about protocol version... I have no idea what should be put there.

4. Method/signal names probably could not be larger. Why the RegisterStatusNotifierItem, RegisterStatusNotifierHost. They could be simply RegisterItem, ReghisterHost.

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.

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...

On Mon, Apr 27, 2015 at 7:46 PM, Dmitry Shachnev <mitya57 ubuntu com> wrote:

Hi all,

We have discussed the GtkStatusIcon deprecation and the future of
our system tray some time ago. At that time I have suggested to
use the Canonical indicators.

Now I realize that indicators are less flexible that the traditional
tray icons, and there were no attempts to standardize them.

So now I think that the StatusNotifierItem specification [1] matches
our needs more closely. It is hosted on freedesktop.org so I think
it may get a wide adoption soon. Also its design is more similar
to the X11 tray design (i.e. drawing of the menu can be delegated to
the client).

KDE's Plasma implements it (though I think it uses org.kde.* instead
of org.freedesktop.*), and has dropped support for X11 tray in the
latest 5.x version. This is another factor that may speed up the
adoption of that spec.

The only downside of StatusNotifierItem spec is that there is no
existing Glib/Gtk+ implementation (at least of the server side).

If we decide to move ahead with this one, we may also try to provide
a client-side implementation in Gtk+ that has a similar API to
GtkStatusIcon, to make porting easier (maybe we can also get it
included into Gtk+ itself).

What do you think?

[1]: http://www.freedesktop.org/wiki/Specifications/StatusNotifierItem/

PS: I'm afraid I don't have enough skills to implement any of this
myself, but I can try to make sure Qt apps work with our tray (as I
know the QSystemTrayIcon code a bit).

--
Dmitry Shachnev
_______________________________________________
gnome-flashback-list mailing list
gnome-flashback-list gnome org
https://mail.gnome.org/mailman/listinfo/gnome-flashback-list

--

Alberts Muktupāvels