On Thu, 02 Feb 2006 11:28:54 -0700 "Aaron J. Seigo" <[EMAIL PROTECTED]> 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 > forward. 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 > perfect. 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) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
