Feedback on implementing Systray2.0 in GLX-Dock

[Marco Martin]

n Friday 07 May 2010, you wrote:
> 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).

Hi,
I'm happy it's being adopted :)

> I hope we can discuss about some points.
> I've tried to sort them by importance (imho of course).

sure :)

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

there are two cases possible: either the menu is completely handled by the 
application or by the visualization, via dbus-menu.

in both cases who will have to open and show the menu is also its owner and 
knows everything about it, including the size.

The algrithm is quite simple, default to open the popup at bottom-left 
compared to the coordinate
if pos.y+menu.height > screen bottom, open the popup at pos.y-popup.height
if pos.x+menu.width >screen.right, open the popup at pos.x-popup.width

the popup size is something that you do have, because is the application that 
actually opens the popup, and that owns it, so knows the geometry too.
if instead the dbus menu is used for popups, is the systray that owns the 
popup and will use the same strategy itself, instead of the application doing 
it.
and this is the only way to know where to do the popup, really, especially in 
the case of floating systray not anchored to any screen position.

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

this is strange does happen with kde clients (probably is because the popups 
couldn't have the actual popup window type, due to a qt problem, i can give 
them the "always on top" flag tough)
this will also be no more an issue with dbusmenu

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

that's a kopete problem (and i'll filter out not allowed tags from the kde 
implementation as well, to be more clear about this point)
anyways a really small html subset is the more simple and "standard" way to 
implement it.
i wanted to support only plain text at the beginning bu was clear that to many 
applications would had too many regressions and if one wants it to be actually 
adopted some compromises have to be made

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

using pixmaps is a supported way, but if i remember correctly i do state that 
the icon name is the preferred way. I'll make it more clear however.

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

full paths in iconnames will continue to always be forbidden, and i'll update 
the spec to be more clear.
the icon theme path is a later addition (of which i didn't really agree, but 
seemed the only way to not break things)
it seems the only way (that said, avoiding full paths in icon names that would 
allow ever broader misises) to make it work when an application uses an icon 
name that is present only in its native icon set, but it's not really 
standard, so wouldn't be present in the hi-color theme. It sucks, but it does 
happen in the real word use cases.

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

another point the spec should be more clear: attentionmovie is a mng, searched 
with the same path name resolution as the icons and is to be used in place of 
atentionicon if present.
however is implementation dependent. a visualization could chose to not use 
it, or not use it if we are on battery, whatever.

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

uhm, perhaps. however you will never be sure it was an actual scroll wheel to 
ask this scroll function, again, it's completely model view based, the client 
shuld never make assumption about the vsualization and the visualization about 
the client.

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

the target is having the org.freedesktop name, but this only when there will 
be a more broad approach. It was agreed in the past to not take the 
freedesktop name until it's an actual recognized spec.

> 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


Cheers,
Marco Martin