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
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
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
> 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
> 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
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the xdg