Feedback on implementing Systray2.0 in GLX-Dock

[Marco Martin]

On Friday 07 May 2010, Fabrice Rey wrote:
> "in both cases who will have to open and show the menu is also its owner
> and knows everything about it, including the size."
> 
> >>> I agree, so the application should place the menu correctly.
> 
> "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"
> 
> >>>actually this is not so simple because you don't take into account the
> 
> height of the dock (or the with if it's on the side)
> By doing that (and that's probably what's done at the moment), the menu
> will overlap the dock.
> 
> Take the case of systray icons being inside a sub-dock, the icon can be at
> 200 pixels from the height. If the menu is 200 pixels height, you can guess
> what will happen.
> If the menu is above the dock, the problem is less critical, but that's the
> WM which will eventually place the menu above or not, and you can't be sure
> it will do that (since the dock is a window of type "DOCK", and such
> windows are usually above all other windows.)
> 
> The best would be to send the orientation to the application :
> top/bottom/right/height
> This way, in the "bottom" case, (x,y) should be the bottom of the menu,
> whereas in the "top" case, it should be the top of the menu.
> The application could guess whether the icon is on the top or on the
> bottom, but it's probably better to let the dock inform it.

again,  the case of floating systray would not be covered, would be easier 
(and would not put visualization hints in the protocol) to adjust the click 
coordinates to something prettier, like  in the case of a bottom dock, the 
coordinates would always be the top left corner of the icon for instance, so 
the menu would also always appear in the same position (not depending where 
was clicked in the icon)


> " i'll filter out not allowed tags from the kde implementation as well"
> 
> >>> I would appreciate :-)
> 
> Also, we should decide what kind of html markers are allowed or not.

the ones in the spec right now are fine i think, plus some other, like <br/>
some ideas about other that would be needed?

> >>> About the scroll, I just wanted to be clear about negative numbers,
> 
> since the orientation parameter only tells if its vertical or horizontal.
> If you scroll up and the sound volume decreases, you will feel something is
> wrong. ^^

ok, will make clear, in fact our mixer decreases the volume with  mouse wheel 
going down, as one would expect

> 
> "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."
> 
> >>> That's a wise decision (not like some who push an API to freedesktop
> 
> whereas the didn't even implement it completely, or test it in real
> condition with third-party projects ...)
> 
> I really hope all the applications will adopt this protocol soon, since the
> old X systray definitely doesn't go with an OpenGL dock.
> 

yep :)


-- 
Marco Martin