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

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

Hi,

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

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.

No, there is no problem. But spec needs work, so this could be changed as well.

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

Since that has changed name should change too.

 

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

Nice catch.

This is 5 years old. I have read message from Matthias Clasen. No one has updated it in 5 years!!!

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

What compatibility? Switching from org.kde.xxx to org.freedesktop is not compatible. Doing this change method names, signals, propartes can be easaly changed - it all about renaming.

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

Bad specification if I need use hacks to make something work. In watcher service I already watch (g_bus_watch_name) for hosts and items so I can emit signals - for item unregistered signal, for host I am emitting registered signal (this is already hack).

The spec is evolving AFAICS (i.e. name changed from org.kde to
org.freedesktop), so I think there are chances to change it.

How it is evolving? By changing name? I think this is spec is not ready to use org.freedestkop. I have only seen recently mail about proposing to move this spec from "Draft specifications that are new and not yet widely used, though they may be used by one or more desktops or desktop applications" to section "Draft specifications that have pretty good de facto adoption/agreement".

Do you know something more?

 

I think we can contact David Edmundson from KDE about this. Should I
forward your mail to him?

You can try, but will it change something? I don't think that something will be changed. If org.freedesktop.StatusNotifierItem is already used by kde, then even more - nothing will change.

I hope that I am wrong.

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

Can we really ignore this? For, example, how are skype or dropbox showing indicators? Will they work with org.freedesktop.StatusNotiferItem?

For example I am using edited exec line for dropbox:

Exec=env XDG_CURRENT_DESKTOP=Unity dropbox start -i

Otherwise no dropbox indicator... Only if notification-area applet is added.

There is bug about adding back notification-area to default panel layout, maybe you should do it...

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

--

Alberts Muktupāvels