Introducing Notification Icons
This is the period of the year when Plasma developers exits from under their rocks it seems, so there i am too, i wanted to blog about that since quite some time, but i am really too lazy lazy lazy to blog :p
As Aaron said, last months i've been quite busy with the implementation of the new systemtray specification. At Tokamak we gathered around a whiteboard and discussed what sucked about the current X systemtray, so... what if we could design it from scratch? well, let's do it! this thinghie interested me so much that i jumped over it in a coding frenzy with i hope a sane amount of pauses to think about it and keep the design sane, scrapping stuff when the design direction seemed to take an ugly direction, process that is still ongoing, so all i will talk about here is still subject to changes, rennnames, replacements etc, nothing "production" still :p
Soooo, why we were really unhappy about the system tray we have now so much at the point to want to design a brand new thing? (and enlightenment people too, and this makes me happy since will permit us to have a really cross desktop design from day one)
There are several reasons, so let's see one by one:
Painting, positioning and behaviour
Right now systemtray icons uses the Xembed protocol, that basically means they are windows owned by the client application process (very very roughly and pardon for the inaccuracy, kinda like the systray was their window manager). This means the painting of the icon is controlled exclusively by the client application, the systray itself has not much to say about that.
It means also, since systray icons have windows, i can't have two system trays, (they would steal icons each other, since the window representing the icon s well, one) and, since plasma is canvas based, the implementation detail of whet xembed is will brutally come out as soon as you try to put another applet over the systray or try to rotate the applet or zoom the view where the applet is, as you can see here :p (yes, that could be kinda achieved with composite, but still a real hack)
Moreover, nowdays our panel is a window that uses argb visuals, so it's translucent when desktop effects are on (that means basically force 32 bits color depth on all windows representing icons). and that's a thing that neither X or graphics drivers (or even qt, before 4.5) were ready for, the amount of bug reports about visual garbage into the system tray or icons that becomes invisible (nowdays still happens with intel cards and the problem doesn't seem to be headed for a solution) were really many and quite discouraging.
Communication between system tray and icon
Or better, lack of thereof in the current spec. Now, the system tray limits itself to embed all the icons there are around (basically windows with _NET_SYSTEM_TRAY_S atom set) and after that, it knows exactly zero about them. Why it's useful for those guys to talk to each other? Well, we all know the problem of cruft in the system tray, having 10-20 icons that steals half of the panel length or more is quite common, unfortunately...
Windows starting from XP made a timid attempt to solve the problem, by auto hiding system tray icons that din't have activity for a given period of time (don't know how since i don't know how their protocol works) or alternatively manually hide icons you hate (ideally shouldn't be necessary but the world is not, nice and fluffy with rocket launcher equipped ponies, misbehavers will always be here)
Now, in KDE (and any desktop that works on X by the way) we can hide icons but only manually, because the system tray has no idea what icons have activity, what are trying to notify something or things like that.
another interesting tought can come by looking at a typical crowded (and not even really crowded) system tray, icon by icon:
- The package manager screaming that i need super-important security updates: it's a system service that needs user intervention every now and then, so it uses the system tray to notify that to the user.
- KMix: it's an hardware control utility, it sits in the systray to give the user a quick way to control the volume without having to dig into the applications menu or systemsettings.
- Keyboard layout: it's a system service, also there to give a shortcut rather than notify something
- Nepomuk: it's a system service usually it's not really useful to have it in the systray, but becomes neat as soon as it goes into the systray just when it's indexing, to notify the user that is doing many disk operations, so giving to him a quick way to pause the indexing if he needs hard disk performance in that moment.
- Klipper: it's a system service, that lets the user manage the clipboard, perhaps it would even make sense to have it in the panel out of the system tray..
- Kwallet: also a system service, access to the saved passwords, not a notifying function at all, it's the typical icon that should be hidden until the user goes explicitly hunting for it.
- Konversation: it's the status of a normal application, but it can be seen also as a communication thing, since those kind of applications tend to notify a lot they can be seen as a separate category (i.e, somebody is trying to talk to you, as in this icon)
- Amarok: it's the status of an application, the icon itself says if amarok is paused or playing and the progress itself. quite used because once amarok plays it can be keeped as a background thing (i.e not in the taskbar and forget about it as long as it emits noise :))
- Skype: as konversation, it's a communication thing, and also there the icon blinks when somebody tries to contact you
- Kopete: communication thing too
So what we have there: several categories:
- Application status, like amarok in this case
- System service: like nepomuk
- Hardware status: like kmix or a battery or things like that
Application status icons in the future can be integrated into the taskbar for instance (did i heard somebody whispering dock? he will be punished :p), and even the other two categories could be separated in two different system trays, it gives more freedom to implement something that could exit from an usability study, with less fears of saying "ehmm, no sorry that can't be done actually..."
The icons can have several statuses, we can think about 3:
- passive: informational, but doesn't require really user interaction, so it's a thing that the system tray can decide to not show if not explicitly asked (in this example would be the package manager when doesn't have updates, kwallet or nepomuk when idle).
- active: the service is doing something or is a control that could be needed any time (nepomuk indicizing, package manager checking for updates, kmix that could always be handy there, battery indicator...)
- Notifying: the icon requires an action from the user, for instance the package manager with new updates, or somebody that tries to contact you from kopete.
So we can now display the notifying ones in a different area of the systray, with a different background and we can hide the passive ones, and show them only when the user presses the unhide arrow.
so what we have now?
The main implementation skeleton is done, the specification it's all based on dbus message passing, since it has to be a cross desktop thing. It's divided in 3 parts: a kded service that keeps the list of the applications that wants to use the system tray (so the list won't be lost due to a plasma restart) the protocol support in the systemtray applet (our systemtray could already support multiple protocols, since it was designed already with this possibility in mind since the refactor in KDE 4.2) and a client library in playground with a tiny test application used as a proof of concept, that can be seen in this video (yes, not a mind boggling spectacular thing, but still important), with also an interesting feature: when you stop the systemtray bookkeeping daemon, the icon magically falls back to the usual legacy system tray icon, so an application using this new protocol would still get systemtray icons when running in a desktop environment that doesn't support the new protocol.
The client library and the dbus interface itself will pass trough a tough api review, so they can still change in a quite significant way (that's why i didn't go really in details in this post).
So don't expect in KDE 4.3 all KDE applications to have been magically converted to this new protocol, but i hope all the plumbing will be there to permit application developers to start considering using this, and i'm really looking forward for other projects to cooperate to have a new unified shiny stuff :D
what if we could design it from scratch? well, let's do it! this thinghie interested me so much that i jumped over it in a coding frenzy with i hope a sane amount of pauses to think about it and keep the design sane
china laptop battery
Response to Vide (Anonimous)
You misunderstand. I was not talking about rotating the old-style icons themselves, I was talking about rotating their _positions_.
Plasma system tray obviously tries to intelligently position the old-systray icons when doing rotation to at least make them look a little integrated into the environment. (They may not rotate-in-place, but they move around like they are spinning.)
Marco Martin: You are right, I know that a "spinning systray" is not a big use case, and that you only used it to show the problem.
But I insist: since spinning any widget is a functionality, and since you can't actually rotate old-systray icons (and are therefore merely moving them around on the fly), then they need to either line them up right when you spin them, or disable rotation for systrays.
I can put up with icons that don't rotate; but icons that fall out of the systray when I rotate the plasmoid just makes it look even _more_ ugly and glitchy.
If you were to fix that, the old-systray icons still wouldn't have the graphical polish of the new systray-spec icons, but at least it would look a little less glitchy.
Discussing this at freedesktop
This is very interesting but I stumbled upon this reading Planet KDE, it would be nice if you posted to the freedesktop xdg mailing list, to be sure interested parties have a look at it. Thanks.
"i wanted to blog about that since quite some time"
Argh! This is *WRONG*! Why does everyone on the internet make this mistake?
The correct way is "I've wanted to blog about that *for* quite some time" or "i wanted to blog about that since quite some time *ago*" (the former is better though).
Also, I think it would be useful for applications to know dpi of systray surface, so apps like akregator could properly render fonts into icons.
May be it would be reasonable to oblige programs to upload all icons/animations first, and switch them by "id" ?
So icons will be serialized, and sent over Dbus ? It means no smooth animation like "pulsation" without overhead ?
@anon, yeah, that's why the client library of the new spec falls back to the old icons when it can't use the dbus way and why our systray supports both protocols (and will for te years being)
oh, and the point is not about making sytemtrays spinning (this just exposes part of the problem) but to be able to separate different kind of icons, be able to do something that totally doesn't look like a systemtray, and only show actually useful icons.
@mutlu: i still have no idea, it will be "officially" presented to others once the api doesn't change every day anymore :)
@qtdeveloper: yep, all you need is a dbus client library, so anything that can attach to it directly ot trough bindings is ok
Kyle Cunningham: i don't think dbus supports network transparecy per se(security implications i guess?), but shouldn't be hard to write a network service that exposes the thing
@mtz:oh, i tought that flickering was solved with qt 4.5 :/ (at least here is) could be a graphics driver problem perhaps
icons still flickers
i am using qt-copy 4.5 and kde4-svn and icons still flickers when changing desktops or minimizing/unminimizing windows
any ideas on what causes this? possible attempts to fix it
it feels like the icons are being refreshed and the flickering happens when the system is under stress(high cpu usage or memory pressures)
any inputs on why this happens will be appreciated
I have to admit I've never understood why you'd want to rotate a window at anything other than 90degrees.
One useful thing would be informational icons that expanded on mouse over to give more information.
Yes, non-qt apps will be able to do this
@qtdeveloper Yes, DBUS is a toolkit neutral system. There is a DBUS API in Qt and a DBUS API that can be used with C programs (Which is what gtk+) uses. Potentially, this would even allow some kind of low level daemon to have a system tray icon with no need for windowing :).
Wouldn't this potentially allow having status icons for programs running on different machines? I'm not sure if DBUS can be piped over the network.
About old systray icons not rotating...THAT'S THE POINT for a new systray spec (well, amongst others) because old icons DON'T KNOW where they are
It's pretty clearly stated in this blog post...
qt only apps?
Will Qt-only (no KDElibs) apps and GTK apps by able to use this D-Bus service specification by simply using DBUS?
If yes, then application developers could implement it easily, use this features under KDE, and under GNOME fallback to old specification. This would by awesome :)
Awesome! You guys are doing outstanding work. :)
I am glad that Enlightenment jumped on the bandwagon, too. And I hope (for you as well as us) that the "cross-desktopyness" falls in place rather sooner than later. What did the Gnomies say about this? Didn't they want to do somthing to the systray, too?
Old systray icons.
Looks like you need to fix the center of rotation on old icons. Right now it looks like the system tray icons fall out of their positions when you magnify or rotate the tray plasmoid.
Not that "spinning system trays" are the key-selling-point here, but since it's possible, you want it to look as good as it can, since odds are, "old systray icons" are going to be around for a while.