Feedback on implementing Systray2.0 in GLX-Dock

Aaron J. Seigo aseigo at kde.org
Mon May 10 16:35:59 PDT 2010


On May 10, 2010, Fabrice Rey wrote:
> we can see that the menu is placed relatively to its top-left corner, when
> it should be its bottom-left corner. The application can't know this fact,
> only the applet can know, that's why I think it should be passed to the
> method.

the only thing i can imagine being useful is a "direction" in which the menu 
should try and position itself relative to the position passed in: up, down, 
left or right. this would solve the issue your seeing for the case where the 
menu is rendered by the application.

> Adrien Gateau told me about using dbus-menu as a workaround, I'll make
> another post to reply to this point.

it's not really a workaround: it is a better way to do this (just as the new 
systray spec is a better way to do it compared to the xembed method :). the 
menu really ought to be rendered by the visualization. it guarantees 
consistency.

we're really trying to get apps away from rendering anything on their own that 
will get shown in the system tray or other places the status notifier items 
will be integrated into the UI.

> "the ones in the spec right now are fine i think, plus some other, like
> <br/>
> some ideas about other that would be needed?"
> 
> >>> <br/> could just be done with a \n in the string.

that would mean having to go through an change all \n to <br/>, and messages 
would have to be careful about not including stray \n characters. it would be 
much easier and clearer to simply require the application to pass in 
consistently marked-up text with no processing of the text (only display) on 
the visualization side.

> I think to keep all the representation equivalent between all docks/panels,
> we shouldn't try to add too many markers. Anyway, an exhaustive list would
> be welcome.

agreed on both points.
 
> "ok, will make clear, in fact our mixer decreases the volume with  mouse
> wheel
> going down, as one would expect"
> 
> >>> yes, because the panel sends -1 to scroll down, and the applet then add
> 
> -1 to the sound.
> If tomorrow another panel sends +1 for scroll down, the user will have a
> bad surprise.

i doubt that is likely, but i do agree that it certainly couldn't hurt to add 
that to the spec for completeness' sakes.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/xdg/attachments/20100510/ad8ac545/attachment.pgp>


More information about the xdg mailing list