"in both cases who will
have to open and show the menu is also its owner
and<br><div class="im">
knows everything about it, including the size."<br><br></div>>>>
I agree, so the application should place the menu correctly.<div class="im"><br><br>"The algrithm is quite simple, default to open the
popup at bottom-left<br>
compared to the coordinate<br>
if pos.y+menu.height > screen bottom, open the popup at
pos.y-popup.height<br>
if pos.x+menu.width >screen.right, open the popup at
pos.x-popup.width"<br><br></div>>>>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)<br>By doing that (and that's probably
what's done at the moment), the menu will overlap the dock.<br>
<br>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.<br>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.)<br>
<br>The best would be to send the orientation to the application :<br>top/bottom/right/height<br>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.<br>
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.<div class="im"><br><br>" i'll filter out not allowed tags from the kde
implementation as well"<br></div>
>>> I would appreciate :-)<br>Also, we should decide what kind
of html markers are allowed or not.<br><br><br>>>> About the
scroll, I just wanted to be clear about negative numbers, since the
orientation parameter only tells if its vertical or horizontal.<br>
If you scroll up and the sound volume decreases, you will feel something
is wrong. ^^<div class="im"><br><br>"the target is having the
org.freedesktop name, but this only when there
will<br>
be a more broad approach. It was agreed in the past to not take the<br>
freedesktop name until it's an actual recognized spec."<br></div>>>>
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 ...)<br>
<br>I really hope all the applications will adopt this protocol soon,
since the old X systray definitely doesn't go with an OpenGL dock.<br><br>Fabounet.