Feedback on implementing Systray2.0 in GLX-Dock

[fab fab]

Hi !
I'm the core dev of GLX-Dock and have recently developped a systray
applet for the dock, based on the StatusNotifier API (I've based my work
on http://www.notmart.org/misc/statusnotifieritem).

I've joined the mailing list to give my feedback about the
implementation of this protocol (forgive me if this is not the good
place, I've talked about this with David Barth 5 months ago and some
time has passed).
I hope we can discuss about some points.
I've tried to sort them by importance (imho of course).

1) the menu : ContextMenu(x,y)
this method has several failures :
 * First, the coordinates are used as the top-left corner of the menu.
In case the dock is placed at the bottom, we want the bottom of the menu
to appear just above the icon, but we don't know the height of the menu.
In case the dock is placed on top of the screen, it would be the
opposite.
The application could guess where to pop-up the menu, by comparing the
coordinates with the screen's size, but it's an extra job, and it
doesn't seem to be done.
Moreover in the case the applet is inside a Desklet (icons are place
inside Containers, which can be either a Dock, a Desklet, or even in any
kind of Container), it could be anywhere on the screen.
At the moment, the application that will summon the menu has no idea
about the orientation and position of the container.
* Second, the menu appears behind the dock, which makes it almost
unusable. Probably because the menu doesn't belong to the dock, so the
WM doesn't place it above the dock. I see no solution, but it wouldn't
be a problem with a good menu placement.

2) Tooltip :
Allowing html-like markers is a kind of wrong good idea.
Good because it allows for instance to stress on some words with a
<b></b>.
But unfortunately it's wrongly used by some applications (for instance
Kopete adds some <qt></qt>, <nobr></nobr> and <br/>, which are not
mentionned in
http://www.notmart.org/misc/statusnotifieritem/markup.html
).
I think what we want is just a small tooltip to indicate things like
current state or failure reasons, not some over-complicated html page.
In the case of GLX-Dock, it uses the Pango markups to render the text in
the dialog. Sticking to the Pango markups could be enough, but anyway
the protocol should be clear about it.

3) Icons :
It should be clearly mentionned in the documentation to avoid using the
pixmaps. It was not very clear for me whether the pixmap is here as a
fallback if an icon name is not found, or just used in case the
application draws its icon itself.
As far as I could see, nobody uses pixmaps (and it's probably better for
performance reasons).

4) IconThemePath :
I think it's not the job of the application to know where are the icons
themes. The dock already has some nice searching functions to find an
icon with a given name. Moreover, the dock can use a given icons theme
and the application has no way to know that.
So this property seems not very useful. A much better way would be to
authorize to pass paths in IconName (it's not clear if this is allowed
or if the icon must be present in an icons theme; paths in IconName
would also make the pixmaps almost useless).

5) AttentionMovieName :
What's the point of this property, compared to AttentionIconName ? is it
some kind of animated png/svg ?
Should it be used in preference of AttentionIconName ?

6) Scroll :
It should be specified how negative numbers are handled (scroll up or
down ?), although this is quite obivous.

7) And finally the bus and interfaces names :
 I'm currently on KDE since they seem more advanced on this point than
Gnome, and all their paths are org.kde.xyz.
Shouldn't paths be org.freeedsktop.xyz ?

Sorry for the long speech, and if some of my remarks are already taken
into account in another more up-to-date documentation.
Tanks for reading me !

Fabounet.

http://glx-dock.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/xdg/attachments/20100507/3a35d78a/attachment.html>