FindLibKNotificationItem-1

If you update various parts of KDE svn today and cmake starts telling you that you are missing FindLibKNotificationItem-1, please checkout (or update if you already have it) extragear/libs/ and install libknotificationitem-1. This is the temporary library for the "client" side of the new system tray protocol we're trialing in 4.3.

If all goes well, then we can nail down the API and ABI for KDE 4.4 and move it into libkdeui where it belongs. Until then, however, we're following the New KDE Library API guideliness (which were written alongside the development of libknotification, actually, with input gathered up on kde-core-devel), and shipping a separate library for it that doesn't carry the hard API/ABI requirements of kdelibs proper. It's a balance between "releasing late and getting next to no testing" and "releasing early so we get testing but without endangering the API quality in kdelibs".

As a recap, the main benefits of the new system are:

• Speed: icons appear "instantly" rather than taking user-noticeable amounts of time to display in the tray


• Beauty: they can be properly themed, resized and painted flawlessly on a canvas; none of this was possible with the old system.


• Alternative display: I expect this to be a nice win for accessibility in that we can now make non-22-pixel-icon system trays. They don't even have to be icons, in fact. They could be text only, audio or even just REALLY REALLY BIG.


• Multiple hosts: one entry can now be shown in multiple places; this not only means things like being able to have a tray on each screen in a multiscreen setup, but also things like being able to integrate entries with their taskbar icons without giving up the old tray or "welding" the system tray and tasks widgets together in Plasma. It also opens the way to divide up the system tray into different widgets specific to a given category of icon, e.g. an area of messaging (and without having to patch all the apps for that specific use case).


• Interaction: the interaction is now completely defined by the host visualization. So, for instance, instead of "middle click" we now have "secondary activation". This allows the application side to provide the functionality but the host environment to decide what triggers it. End result: greater consistency.


• Application information: applications can now say "this entry is about hardware" or "this entry needs attention!" Now that the host can know the type and state of a given entry (and, really, any other piece of information we might find useful) we can finally provide things other systems have had "forever" like intelligently showing/hiding icons based on their usefulness to the user at that point (and yes, this will remain configurable :).


• Backwards compat: it still works with the old xembed system :)

I sent a preliminary email a week or two back to the freedesktop.org xdg list on it where it received some feedback. I really hope to see some uptake on this from other projects as a result, especially as we publish more formal specifications based on the DBus interfaces.

As this plays rather nicely into Canonical's "rethink notifications" activity I'm hoping they might pick it up and work on an upstream-able implementation for the GNOME desktop. In fact, I think the introduction of the messaging indicator library is a misstep in terms of cross desktop usefulness (what happens when you run a messaging indicator enabled gwibber in KDE, XFCE, or whatever other desktop?) and application patching efforts. Everything they have done there is (quite intentionally) 100% possible with the new notification area spec we're introducing by simply marking the entries in the application as type "Messaging". Then there is no need on the application side to figure out when to switching between the "traditional" system tray / notification area approach or the messaging indicator approach, it will work with all older (or just different) systems, etc.