Proposing the StatusNotifier specification

[Mikkel Kamstrup Erlandsen]

2010/1/14 Marco Martin <notmart at gmail.com>:
> On Thursday 14 January 2010, Mikkel Kamstrup Erlandsen wrote:
>> 2009/12/17 Aurélien Gâteau <aurelien.gateau at canonical.com>:
>> > Hi,
>> >
>> > A few months ago, Marco Martin proposed a new specification to
>> > freedesktop.org [1] (at this time it was named NotificationItem, it has
>> > since then be renamed to StatusNotifier to avoid confusion with the
>> > existing Notification spec).
>> >
>> > The goal of this specification is to replace the old x-embed protocol
>> > used by applications to export icons in the system tray/notification
>> > area. The new specification presents a number of advantages, quoting
>> > Marco:
>> >
>> > """
>> > The new protocol is based upon D-Bus, and separates the presentation
>> > of the items from the logic, in our case the painting is completely
>> > controlled by Plasma and the applications registers via D-bus (with a
>> > small clien library shared across KDE) to a central server, while
>> > there can be zero or more instances of the systemtray.
>> > if either the serve or no instances of systemtrays that supports this
>> > protocol are registered the system will fall back using the old
>> > freedesktop.org systray specification.
>> > """
>> >
>> > The latest version of the specification can be found here:
>> >
>> > http://www.notmart.org/misc/statusnotifieritem/
>> >
>> > This specification is already implemented by KDE in kdelibs [2] and
>> > Canonical is working on an implementation for GNOME, libappindicator [3].
>> >
>> > We believe the specification is a significant improvement over the
>> > x-embed protocol and is now mature enough to be accepted as a
>> > freedesktop.org specification.
>> >
>> > Having the specification accepted now would make it possible for both
>> > implementations to switch to the "org.freedesktop" DBus namespace now,
>> > thus simplifying code because there would be no need to register two
>> > names.
>>
>> I am wondering if we need some event timestamps for the methods on
>> org.freedesktop.StatusNotifierItem? Window managers that does focus
>> stealing prevention will not allow apps to focus windows at whatever
>> times suits them without a valid event timestamp. This goes for
>> Metacity atleast, perhaps also Mutter...
> is it someting for the dbus protocol?
> Shouldn't be something more for the client library, to take care raising the
> window with the timestamp of when the activate signal arrived? (as opposed to
> when the signal originated, that would add complexity to the dbus protocol)

The point is that this might or might not work, depending on the exact
timing policy of the window manager. If your timestamp is a micro
second off because of the DBus round trip the wm might block the focus
attempt. But to be honest I don't know exactly how WMs decide these
things, I just know that focus-attempts almost always fail under
Metacity unless you pass the right timestamp.

And I don't think it will complicate the protocol all that much. It's
just adding an arg of type 'x' or 't' to the methods. It should be
allowed to pass 0 here with the chance of the client app not being
able to focus the window.

-- 
Cheers,
Mikkel