the current spec does not directly require any behavior from clients
when a systray host, leading to an issue where clients do not re-register
their items when a new host appears
when using an in-process systray watcher, as the current implementation does,
the best choice for maintaining consistency for systray items across restarts
is to cache them according to the current dbus session. the process of setting
up the item will validate it on subsequent restarts, and changes to the session
will clear the cache
fix T2786
according to the StatusNotifierItem specification, applications
register "service org.freedesktop.StatusNotifierItem-PID-ID" on the
session bus, and then "must register the unique instance name
to the StatusNotifierWatcher".
some applications, such as steam, instead register the path that they
will run on (/org/ayatana/NotificationItem/steam) and then expect the
watcher to register the method call's send id bus: this is totally bogus.
to catch this, when registering the new item the enlightenment watcher must
first determine if the item is spec-conforming. if yes, proceed as normal.
if no, pretend the application knows what it's doing and try to make things
work as expected anyway
for more details, read the full spec here
http://www.freedesktop.org/wiki/Specifications/StatusNotifierItem
fix T2763
previously, this would throw dbus errors (or not) and then do nothing in
many cases. now it manages bus/path names more effectively and falls back
to binary image data when an icon path is not available
fix T2626 and probably some others
This fix a bug that was empty dbus notification when shelf is moved and
also allow multiple instance if some day we drop xembed support.
Patch by: José Roberto de Souza <zehortigoza@profusion.mobi>
SVN revision: 82492
Marcel Hollerbach
Mike Blumenkrantz
Mike Blumenkrantz
Lucas De Marchi
Carsten Haitzler
José Roberto de Souza
Lucas Joia