kscd, system tray

i've got several outstanding bugs to squash in kscd that represent regressions over 3.1. things keep coming up, or i keep getting prematuraly tired in the evenings: i have a lot on my plate at the moment, both for work and personal life. but i have to get the kscd stuff done this week. i think i'll take a couple hours out of work to do so. the problems don't seem very difficult, aside from the Linux ide-through-scsi emulation bug. that one's going to be annoying because it's likely due to work done on libwm by another hacker, so i'm not intimately familiar with every LOC in there and this just breaths of one of those annoying OS-specific quirks. such is life.

i've learned a few things with kscd. first, kde's libraries have improved radically over the years. there's a lot of legacy code in kscd that really reflects the state of KDE at various points. it's been sort of like sifting through sedimentary layers as an archeologist. i've also learned a few things about user interfaces, which is always cool. but i've also learned that i hate, with a passion, the system tray.

i've worked on all three ends of the system tray code: the client (kscd), the manager (the systray kicker applet), and the glue (XEmbed). the latter is the only one i haven't committed any changes to CVS for, but i have tinkered with it to see how it does and doesn't work. using the system tray from an application is amazingly annoying, for instance: when it's clicked you need to close or open your main window, but not quit. but to differentiate between that sort of close and an actual window close one needs to code separate paths; oh, and be careful not to break session management in the process. i've seen that happen more than once, and i managed to do it myself in kscd. the lovely thing is that we have this finicky, brittle code duplicated in several apps in CVS. bogus.

one might think that this is all to make the systray apps lifes easier, right? nope. because the systray icons are out of process, managing things like background repaints is a bitch. but so are things like sanitizing the UI as you don't really have any access to the process that handles the context menus, as just one example. the system tray also doesn't know what apps are actually using their icons, or how important they are to be shown to the user; the people who designed the current systray mechanism didn't think about the need for such things.

as a side note: kde's systray applet's layout code sucks donkey nuts: It assumes a certain size icon for its grid, which results in cutting off wider icons which some, ahem, enterprising apps employ to be all fancy. which leads me to another gripe: to change the size of the default icon, someone had to go through all the KDE apps and change how they loaded the icon. what bullocks! what happens the next time we want to change that size? or if we want to make the size configurable? or, more pressingly, what about all the apps outside of KDE's CVS tree?

what other part of KDE's GUI that should be standardized does every app implement on its own with no help from the libs to keep things consistent? i really can't think of any. menus, toolbars, dialog buttons, etc, etc. the systemtray stands out like a sore thumb.

i won't even start in about XEmbed. it's such a hack. a necessary one for some things, but still a hack. it isn't a proper component model, and it puts an uncomfortable divide between the systray client and the systray applet.

where am i going with this? well... i want to see the current system tray mode deprecated within KDE. keep it around for bakcwards compatability, sure, but going forward provide a BETTER way. one thing that is obvious is that we need some way to communicate between the client and the host (e.g. whatever ends up displaying the systray icons; right now it's an applet, but it doesn't have to be, of course...). another thing that's perhaps less obvious is that the host ought to be able to standardize the display as much as possible, from context menus to icons. using IPC rather than out-of-process windows would allow all that, and would, as an added bonus would clean up the miscelaneous issues of background painting and the oh-too-easy-to-lose nature of the current systray icons.

now, we could of course use X atoms to pass bits of info back and forth, but we really just end up duplicating DCOP without all of its benefits. (if you haven't guessed it yet, i'm working on a DCOP protocol for the systray.) with a DCOP service, KDE apps should be able to access the system tray in a much more dynamic method while easily allowing multiple system tray handlers, multiple ways to view and interact with the system tray contents AND consistent UI. the big challenges are menus that appear in the host defined by DCOP messages from the clients and custom (e.g. bitmap) icons over DCOP.

at the current time, it seems quite likely that the current KSystemTray class used by clients will need quite some augmentation to its public interface and pretty much a complete rewrite internally. usage will remain nearly the same, just with some new methods to define menus, etc.

obviously, this is a KDE4 thing, but i'm starting early so it has a real chance of happening. i've got several other things on the go as well, so i'm giving myself lots of lead time. one i've got a draft of the full DCOP spec, then i can start solliciting for support from other developers. but i'd like to put the bug in people's ear now =)

oh, and since this is a KDE4 thing, if we do end up adopting DBUS for KDE4 (which seems likely) then by implementing the new systray protocol in DBUS everyone can have access to it, even non-X apps since DBUS is designed to be completely agnostic w/regard to desktop or windowing system. try that with XEmbed, why don't you. ;-) this also opens the door to making it a FD.o standard to superscede the current XEmbed-based systemtray abomination^Hspecification.