This is another pretty long post on the new system tray. Since the last post things have cleared up a bit (and i hope the api it’s a liiiittle bit more stable too) so i think times are ready for a slightly more technical description of all the machinery there is in place.
So, what are the parts of the system tray spec and more important how to use it and port existing applications?
First of all, the protocol is totally based upon dbus, so examining what are the registered services let’s see what are the (three) actors involved (yes, eventually some day those org.kde.* will become org.freedesktop.* :D):
org.kde.NotificationItem
every application that wants to use the systray has to expose this service, that will be called org.kde.NotificationItem-pid-index, where pid is the application pid and index is an unique thing that ensures no duplicate names, so an application can even register more item it it wants.
This thing is what defines everything that a system tray icon was and a bit of information more: it exposes the icon, a tool tip, the category of the item (status of a generic application, communication related, system service or hardware info) and the status: is it idle? is important that is visible? or is it really important to require user intervention?
It offers also some actions to interact with: activate, secondary activate, context menu and scroll. Notice how it doesn’t talk about left or right buttons, because right now we are providing a thing that looks like a system tray, to have a smooth transition, but we are not anymore forced to use that, we can have for instance some of the items embedded in the taskbar or have different representations, maybe interacted with the keyboard or who knows…
org.kde.NotificationItemWatcher
A system tray can come and go, for instance in Plasma the applet can be added or remove or the plasma process can be restarted, moreover the application can run in an environment that doesn’t (still:) support the protocol, so it’s needed something that keeps track of registered items and registered hosts for items (there can be more), all the system tray instances will register themselves here and take from here the list of items registered (NotificationItem implementations must register here too)
When the org.kde.NotificationItemWatcher is not up and running or it does not have instances of org.kde.NotificationHost registered all the items must automatically fall back to the traditional xembed type of icons
org.kde.NotificationHost
This service is registered by the system tray itself, it doesn’t offer properties or functions, it’s just used by the system tray (or whatever thing that can display an org.kde.NotificationItem) to announce its existence to the watcher to make possible to be automatically unregistered when the systray is closed (even if it crashes)
There can be an arbitrary number of hosts registered, to make possible both more simple things like having a system tray for each monitor in a multi monitor setup or more interesting stuff, like offering a different representation for different items category, for instance:
- Putting the hardware status items and system services in a traditional tray, and we will be sure only that low level stuff will be displayed here
- Integrating the application status items with the taskbar, we could perhaps display the minimized tasks without text in this case, or collapsing them in a popup menu, or whatever a brilliant idea will come 🙂
- Collapsing all communications related items in a single item into the panel, that would be a “messaging center”, where i don’t care if messages are arriving from kopete, kmail or konversation, i only want to know what people are saying to me…
Those are just abstract ideas for now, it’s not said that they will be implemented in this way or that this description is necessarily the best way to go, it’s just a little scenario to provoke some thinking on what is the best way to go and to not take as a given that the current way is indeed the current one, time will tell, what counts for now is that we are no more forced to display this stuff in a pre determined way.
Last but not least, where is the code?
System tray plasmoid and kded
The system tray plasmoid is basically the org.kde.NotificationHost part that does all the interaction with org.kde.NotificationItem and includes full support to the spec for KDE 4.3, it can also be configured to show only certain categories of items, giving a first implementation of the ideas i talked before (i.e. one systray for hardware info, one for application status etc.)
The plasmoid ships also a kded that implements the org.kde.NotificationItemWatcher part, if the daemon goes down, or all systray plasmoids go away, all the items becomes traditional system tray icons on the fly.
KNotificationItem library
This is the client library to be used in place of KSystemtrayIcon (with a very similar api) it takes care of all the dbus talking and is quite simple to use, it just offers some functions to set properties like icons and tooltips and some signals to notify about the various types of activation from the user.
This will go into extragear on the next few days, so applications can start to experiment with it, keeping in mind that is still experimental. After 4.3, it will head into kdelibs for KDE 4.4, at that date and time it will be completely api stable.
I have two questions.
First, does it offer some way to notify the system about what the parent window of the notification is? So, for instance, if you move files from one folder to another, the resulting notification will be identified as being associated with that window. Or if you burn a disc with K3b, that notification will be tied to the k3b window where the burning is taking place.
This would be very useful, for instance, for embedding progress meters in the taskbar or other application-specific areas. See here:
http://forum.kde.org/easy-beautiful-progress-notification-in-the-task-bar-t-43570.html
The other question: does it provide some way to notify the system about what the action is being carried out on? For instance, if it is moving a file from folder_a to folder_b to another it can say “I am working on folder_a/file and folder_b/file”, or if it is burning a disc it can say “I am working on /dev/cdrom0”. This would allow file managers and other programs to identify what an action is being carried out on.
An example with dolphin is here:
http://forum.kde.org/file-progress-in-icon-t-38897.html
Another example would be if you are burning a disc with k3b, and open up another cd/dvd burning program, the program can not only tell you that a disc is being burned already, but tell you which drive is being burned and what its progress is without having to know anything about k3b, or even that k3b exists.
I understand if these are considered outside the scope of the notification system you are designing, and if they are already possible all the better, I just thought I would bring them up in case they are useful. Better to do so now rather than when the API is already set in stone.
for the first question yeah, the window id is a property that is carried by NotificationItem, so this part is ok,
i perhaps see harder the association of jobs with window ids, i don’t think is an information that can be fetched in some way, even if never say never..