Carsten Haitzler (The Rasterman)
raster at rasterman.com
Fri Feb 3 06:18:02 EET 2006
On Thu, 02 Feb 2006 11:28:54 -0700 "Aaron J. Seigo" <aseigo at kde.org> babbled:
> (sorry to break the thread, but after a recent email change i managed to get
> unsub'd from this list and never re-sub'd. bad aaron, bad aaron! ;)
(read your blog about the systray - doesnt anyone doign desktop stuff have a
blog about how much it sucks by now? :) )
> what rasterman is suggesting is essentially what i suggested a year or more
> ago, so i'm certainly in favour. a few other twists:
yup. good to hear alike views exist.
> text along with the icon should be mandatory for accessibility purposes (it's
> hard for screenreaders to read a status icon unless there's text with it
> too ;)
agreed. at the least NETWM_NAME must be useful.
> autohiding: we have hiding in the KDE systray applet, but it's pretty
> rudimentary because we have no way of querying the app as to its status (or
> the status of its icon). a status (normal, interesting, urgent, dormant) was
> already discussed, and they may well be enough.
indeed - i touched on thsi too. it at leas shows there's a common need.
> multiple trays: it should be possible to represent the systray in more than
> one location (think: multi-screen setups). so any proposed spec should not
> have built in limitations (as the current one does) as to having one and only
> one systray consuming the systray data.
indeed again - that was another thnig that virtualising the display fixes.
> systray and x11 windows: it would also be very nice if the systray didn't
> require any UI elements in the source app either. this would allow daemons to
> utilize the systray without gratuitous UIs having to be developed on top of
> them. this is why i suggested using IPC versus XAtoms. though even just
> getting rid of the "systray by embedding x11 windows" concept is a great step
i am of 2 minds. you do have a point - but it makes barrier of entry higher and
you do discard a perfectly workable existing ipc mechanism (x11) that almsot
all existing tray apps already share. it works across networks, it gives a
central connection point (the xserver) and allows us to recycle a lot of
existing code that does things liek fetch/parse netwm icons etc. :)
> as for standardized menus, i'd say don't bother. i looked into it and came up
> with a similar scheme as to what was suggested but then i looked at the menus
> people were actually showing and decided it wasn't worth while. just let them
> show their menus at a screen coordinate and be done with it. why?
i am of 2 minds with this too - it is complex and a fair bit of work, but has
some standardisation benefits for like 95% of systray apps. it again allows a
daemon process to have a systray with only simypl using xlib to conect to x and
use it as an ipc mechanism. it needs no widget set attached to it to ave a menu
at least then :)
> menu items may update while the menu is being shown; some menus show things
> other than just text; etc... i don't see the overwhelming benefit of doing
> the menus in the systray process compared to the effort required to get it
well i covered text and icons, check and radio buttons, submenus and
separators. this coveres all the menus i've seen so far for systray apps...
except the volume slider (a non-menu thing) and thats why we can advertise a
root-relative geometry for the systray that may have a "menu" action happen
(right mouse click for example) so the app can then pop up its "menu".
but anyway - the important thing here is that there seems to be a fair bit of
restlessness amongst the natives and somethnig should be done... so far a fari
bit of positive feedback overall - it's mroe a debate on some details and more
complex things being omitted.
> Aaron J. Seigo
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
> Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) raster at rasterman.com
Tokyo, Japan (東京 日本)
More information about the xdg