agateau.wordpress.com is outdated. I moved my blog over to agateau.com. See you there.

Indicators, notifications and co

Introduction

Jonathan post about indicators has been received with various feelings, ranging from interest to questioning or plain hostility. Since I get more and more people asking about this indicator thing, I figured I should try to explain what indicators are, how they are different from notifications and answer a few other frequently asked questions.

Disclaimer: The opinions of this post are my own, they do not necessarily reflect Canonical position.

Indicators for the user

Indicators are a way to get permanent informations, rather than ephemeral ones like notifications. I find it easier to explain the difference with use cases.

Imagine you receive an incoming message from your IM client while you are away from your machine. A notification gets shown, but this notification goes away after a few seconds. You just missed it.

Since the IM client supports indicators, it also created an indicator for this incoming message. When you come back to your desk, you notice the spark on the indicator plasmoid. Clicking on the plasmoid popups a menu listing all indicator-enabled running applications. Below your IM application entry, there is an entry for this incoming message you received. You click the entry and the chat window is brought to the front.

You would also like to know if you have any unread message in this “From Boss” mail folder. So you look at the mail client entries, and notice that “From Boss” appears, with a count of 2. You click the “From Boss” entry and your mail client is brought to the front, showing the first unread message in the “From Boss” folder.

The "Indicator Display" plasmoid showing indicators from Kopete and KMail

You are now busy working on this report due to your boss for yesterday. You turned your status to “Busy, Do not Disturb, Will Bite”, but that does not stop people from sending messages to you. If your IM client is smart enough, it can disable notifications and only create indicators. When your report is finally done, you can relax, click the indicator plasmoid and start chatting with the people who tried to reach you before.

Back home, you decide to spend the evening watching a movie on your laptop. Since you are running a fullscreen application, notifications are disabled: you do not want to get interrupted by this IRC message from your friend while Bruce Willis is busy saving the world. When world has been saved, you can click the indicator and catch-up with your friend.

Indicators for the application developer

libindicate-qt provides two objects for the application developer: QIndicate::Server and QIndicate::Indicator.

The application typically starts with instantiating a server, declaring its desktop file and “server type” (a way to group applications, for now the plasmoid only shows servers with the “messaging” type), then calling the show() method. As soon as this is done, an entry for the application appears in the indicator menu. When the user clicks on this entry, QIndicate::Server emits the serverDisplay() signal. All you have to do is to connect to this signal and bring your main window to front.

When an event worth mentioning to the user happens, you instantiate a QIndicate::Indicator for it. An indicator can have a few properties:

  • name: the text to display
  • icon: a QImage for your indicator
  • time: a QDateTime describing the time of the event, if relevant
  • count: an int representing a count, if relevant
  • draw_attention: a bool which must be set to true for the plasmoid to display its spark

“time” and “draw_attention” are useful for indicators representing events like IM messages, while “count” can be used for example by mail clients to create indicators for their folders.

When the user clicks on the indicator entry, QIndicate::Indicator emits a display(QIndicate::Indicator*) signal. Connect to this signal to perform the action relevant to this indicator.

(Note: the properties listed here are those used in the case of messaging communication, but the Indicator API is flexible enough to let you define other indicator properties)

FAQ

Couldn’t this be implemented within KDE notification system?

The KDE notification system can represent notifications in a few ways: showing popups, playing sounds, writing to log files, running programs…

I tried to implement support for indicators as a new way for the notification system to represent notifications, but it did not work because the notification system lacks the server/indicator structure. For example to implement the feature which brings the application to front when you click its entry, I ended up having to remember the window id of the first notification I received so that I could bring back this window. It was unreliable (what if the first window was gone by that time, or even not specified?) and it was not possible to do things like showing a count of unread emails in a folder for example.

Couldn’t this be implemented with KNotificationItem?

KNotificationItem is a new xdg specification which aims at replacing the SystemTray specification. Quoting the specification itself: “It is intended to be complementary but not directly related with the Freedesktop’s Desktop Notifications specification and is aimed as a replacement to the Freedestop System tray specification.”

In short, it is system tray done right. It is a huge step forward as it makes it easier for the application/toolkit to implement system tray support and it makes it easier for the system tray host to display these icons in a way which is consistent with the rest of the desktop interface.

It expands on the system tray spec by introducing a notion of status (Passive, Active and NeedsAttention), a possible icon overlay and a category (ApplicationStatus, Communications, SystemServices and Hardware).

It has a few features indicators do not have, such as tooltips and support for right-click, middle-click and mouse wheel events.

It does not however provide an equivalent to the server/indicator structure, or to the “count” and “time” properties. This makes it impossible to implement indicators on top of KNotificationItem.

Still, the two systems have quite a few commonalities, so it may make sense to merge them in the future.

Where does it come from?

libindicate has been developed by Canonical Desktop Experience team, as part of the Ayatana initiative. Ubuntu 9.04 (Jaunty) was the first version of Ubuntu to feature it on the GNOME desktop.

The upcoming Ubuntu 9.10 (Karmic) expands on this by providing a Qt binding for libindicate, adding support for indicators to a few Qt and KDE applications and a plasmoid to display indicators on the KDE desktop.

Is it Ubuntu specific?

No. The Canonical Desktop Experience team considers itself as an upstream developer team. As such we release source tarballs, which are then packaged by Ubuntu, but can be packaged by other distributions as well.

Here are the links to download them:

Does it depend on GTK+?

libindicate-qt depends on libindicate. libindicate used to depend on GTK+ at runtime, but it’s not the case anymore.

It still depends on GTK+ at build time because compiling libindicate from source produces libindicate.so and libindicate-gtk.so. libindicate.so depends on GLib, but does not depend on GTK+. I recon depending on GTK+ to build the library is a problem for source-based distribution like Arch Linux or Gentoo, patches from autotools masters are welcome. A bug has been filled to track that issue.

It is a cross-desktop system: indicators from KDE applications show up in GNOME indicator applet, indicators from GNOME applications show up in KDE plasmoid.

What applications support it?

On the KDE side:

  • Quassel
  • KMail
  • Konversation
  • Kopete

Upstream processes for these patches are in various states. Quassel patch is already in their git repository, Konversation patch has been submitted but needs some work, KMail and Kopete patches have not been submitted yet.

You can find all the patches here.

On the GNOME side:

  • Evolution
  • Gajim
  • Gwibber
  • Pidgin

What is the difference between the “Indicator Display” plasmoid and the “Incoming Message” plasmoid from kdeplasma-addons?

Both plasmoids have the same goal, but the “Incoming Message” plasmoid tries to implement this goal with application-specific code: it has specific code for Evolution, KMail, Pidgin, Kopete and XChat.
The “Indicator Display” plasmoid on the other hand relies on applications to use libindicate and does not contain any application-specific code.


36 Comments on “Indicators, notifications and co”

  1. Nice writing. I hope to not mess up the terms: From what I know, KNotificationItem is the next generation of “QSystemTrayIcon”, and this is obviously not matching the functionality that an indicator display needs.

    Still, I fail to see why we can’t use the existing extenders in Plasma’s system tray for that, where those notifications appear (those for file transfers etc.)

    You say: “Indicators are a way to get permanent informations, rather than ephemeral ones like notifications.”

    So put some “permanent” flag in the notification spec and you’re done. If you need more features, the Plasma team has worked on notifications for around half a year, which was plenty of time for you to coordinate development with them. Wouldn’t this have saved you quite some work?

    • Aurélien says:

      “Still, I fail to see why we can’t use the existing extenders in Plasma’s system tray for that, where those notifications appear (those for file transfers etc.)”

      I think it would look quite huge if presented as extenders. Can you imagine the attached screenshot represented as extenders? if you add let’s say 3 KMail folders it would become really tall.

      “You say: “Indicators are a way to get permanent informations, rather than ephemeral ones like notifications.”

      So put some “permanent” flag in the notification spec and you’re done.”

      It’s not only about permanent versus ephemeral. The main missing part is that there is no server/indicator structure in the notification system, meaning it’s impossible to represent a main item (the application) and its sub items (the indicators).

      “the Plasma team has worked on notifications for around half a year, which was plenty of time for you to coordinate development with them. Wouldn’t this have saved you quite some work?”

      libindicate is roughly one year old (first commit was on the 29th of October, 2008 and this probably happened after some upfront design work). I only had to build a Qt binding for it and a plasmoid.

      I do not think it would have been faster to integrate the necessary changes to Plasma (assuming they would be accepted), implement a GNOME equivalent and port existing libindicate-enabled applications to use it instead.

  2. Markus says:

    Do you provide binaries for other distributions? Right now I don’t see the point of indicators, but if I try it myself, I may think different.

  3. alf says:

    I think this makes things easier and organized… But I’d like it to be integrated with systray indicator(the icon with “i” letter) so I can have one place to go when I missed something. So when I click the “i” icon there would two categories:one for communications, and the onther one is for other categories…

    • Aurélien says:

      This can probably be worked out, but the (i) icon is part of the systemtray plasmoid, so getting indicators integrated in this would require integration of indicators in Plasma. Unfortunately, this does not seem very likely to happen for now.

  4. alf says:

    That’s why I made the comment above is because the UI of your indicator will overlap or will be covered with the notifcation bubbles in case you click it and then a notification bubble comes out…

  5. mycroft says:

    As a kubuntu user under karmic, I had no idea up until now why I had lost Kopete notifications. (I am not sure that I ever had them under KDE 4.0 though)

    Now I realize that to get “notifications” (in a broad sense, I understand the difference between notification and indication even if it is tenuous) from all my applications, I do not only need a systray, but a systray AND something else.

    This is really confusing. I have no idea how a non-tech user who is not reading planet KDE is going to guess that after the upgrade to Karmic you need to add a new indicator plasmoid.

    IIRC during upgrade, the desktop configuration is not modified, you need a clean install if you want to use the new default desktop.

    • Aurélien says:

      You don’t need to add an indicator plasmoid to get Kopete notifications. Indicator support in Kopete is implemented as a plugin, and it does not disable notifications.

  6. mycroft says:

    Thanks for your reply.

    So something else is wrong with my kopete settings. I’ll try to find out what it is.

  7. mat69 says:

    I like that concept.:)

    I have experienced very often that I miss pings etc. in irc (konversation marks the tabs red, so that helps me then), mails in kmail etc. simply because I’m not there at the point when the notifications are displayed and no having them constantly on would not be a solution but rather a waste of space (imo they use too much space atm anyway).

    So as mentioned I miss a lot of stuff and the workaround atm is to switch to all the apps where I could have missed stuff and check if I actually missed something. As it appears your tool is the solution to my problem.

  8. There are a few things I do not like about the Plasmoid: first of all that it is a Plasmoid. In my opinion it should be in the systray and autohidden when there are no new messages. I don’t need a prominent indicator showing me that I have no new messages. The way it is now it’s just taking away even more space from the panel for things I normaly don’t want to see (like the battery plasmoid and the device notifier – both fixed in 4.4).

    Then I think there is a design mistake – not done by you but done by the developers who did the indicator. Emails, instant messaging and IRC and three completely different topics and they do not have anything in common (except that it is communication). When I’m using instant messaging I want a notification at once as it is instant, while I normaly ignore mails till I decide when to reply to them. That’s why I think having one indicator for all kinds of communication is just wrong. I think the right approach would have been to use the new possibilities of the systray and provide the information directly in the KMail icon or in the Kopete and Quassel icon. That is extending the current state by providing more information.

    Last but not least I think using an email icon for the plasmoid is not the right icon as the indicator is for all communication. And I think the difference of the icons for no new message and new message is not strong enough

    • Aurélien says:

      “In my opinion it should be in the systray and autohidden when there are no new messages.”

      I understand this problem. As you said, it is possible in KDE 4.4 to embed a plasmoid in the systray, which will help reduce the space taken by this plasmoid, unfortunately it does not work with KDE 4.3.

      As for autohiding it, the problem I see with this is that a user adding the plasmoid to a panel will see nothing, which feels wrong. An idea could be to make it only a few pixels wide (or tall depending on the containment orientation) so that it does not waste too much space.

      “Emails, instant messaging and IRC and three completely different topics and they do not have anything in common (except that it is communication). When I’m using instant messaging I want a notification at once as it is instant, while I normaly ignore mails till I decide when to reply to them.”

      I agree. But keep in mind that you still have IRC notifications showing up. It’s also worth noting that it is up to the application to decide whether it should turn the “draw_attention” flag of their indicators, causing the plasmoid to change its icon.
      For example, right now KMail shows the count of unread messages in selected folders but does not turn the “draw_attention” flag for them, so the indicator won’t turn on when you get a new message. You can imagine that it could get smarter in the future, and turn the flag on when a message arrives in a specific folder, or from a specific sender.
      The advantage of having this plasmoid over one icon per application in the system tray is that it reduce the clutter in said system tray.

      “Last but not least I think using an email icon for the plasmoid is not the right icon as the indicator is for all communication. And I think the difference of the icons for no new message and new message is not strong enough”

      Yes, the icon is not really adapted, I agree. In fact the (i) icon in the system tray is quite nice, but using two (i) icons is probably not a good idea…

      • Aaron Seigo says:

        “In fact the (i) icon in the system tray is quite nice, but using two (i) icons is probably not a good idea…”

        there’s no reason we couldn’t put a “message” icon next to it, however. the system tray already supports putting entries there, you just need to set the appropriate Status.

        so ‘i’ for information and $SOMETHING for messags; sounds sensible. the messages icon could come and go if the user wishes.

        moreover, that messages icon could show only when there are messaging apps running and could amalgamate all the “messaging” notification items.

        that would eliminate the overlap between, e.g., kopete’s system tray icon and providing indications.

        and it doesn’t need a separate library or a separate system to accomplish it. you’d also stand a reasonable chance to get such patches upstreamed.

  9. Aaron Seigo says:

    the entire problem with this is, as i’ve said before both privately to various people involved as well as publicly as time has gone on and it becomes increasingly apparent that the idea is to stay the course vs try to collaborate, is that it’s Yet Another Unneeded System.

    there’s another library to learn to use and load at runtime.

    there’s another system to attach our applications to.

    there’s another UI concept that we need to rationalize with the system tray and tasks widget.

    you say “it might make sense to merge this with the new notification item system”, and you’re absolutely right. not only does it make sense, it was designed to allow for such things! the entire POINT of the new system is to break out from useless icons that can not be managed or integrated or sorted and turn them into houses for application status and information that can be presented in any number of ways.

    instead, what you’ve managed to accomplish is a bunch of patches to apps to support this new library that isn’t common at all yet and to make app devs scratch their heads wondering when to use this or when to use the system tray or …

    app devs should NOT have to care about this kind of stuff. they should have ONE place to sink their data and the VISUALIZATION(S) should determine how to sort it out.

    thus imho, as it stands, this indicator library is broken in its design. the intentions are good, but the implementation is awry. but it can be fixed.

    i’ve mentioned this a few times to people working on these things @ Canonical over the course of many months. but i end up asking myself: is there really any interest in doing things better, or should i save us all the hassle and begin ignoring ayatana as a fork-producing downstream project?

    • gp says:

      I’m totally agree with you.
      The idea is good but the way to achieve this it it right?
      Totally agree with you.

      giuseppe

    • Aurélien says:

      “it becomes increasingly apparent that the idea is to stay the course vs try to collaborate”

      Depends on what you mean with “collaborate”.

      Assuming you agree that in its current state KNotificationItem does not make it possible to implement what indicators do, how should we collaborate?

      I can only imagine two solutions:

      – We throw away our working implementation (which predates KNotificationItem) and extend KNotificationItem to meet our needs, adding the concept of Indicators as children of KNotificationItem.

      – You rebase KNotificationItem on top of libindicate. NotificationItems can be represented as libindicate servers, using the server type to match NotificationItem categories. libindicate Server concept would have to be extended to provide a few more properties.

      • notmart says:

        at the moment it can’t do -exactly- that, yeah, but the machinery is almost there.
        protocol-wise all is needed is probably a new property, with a data structure with that info, like (boss:2, joe:5) and a signal that tells it’s changed,
        then how to do a proper visualization for that is just a secondary (and changeable any time) matter..

        • Aurélien says:

          It’s a bit more involved: an indicator can have any number of properties (see the list of predefined ones in my blog) and can emit a signal when it is activated.

          Therefore I don’t think the indicators of a server can be reduced to a property dictionary. An indicator must be a first class DBus object IMO.

      • Markus says:

        I didn’t see much involvement of Canonical when the new notification specs were developed for KDE 4.2, so your “predates” argument is not really valid, because Canonical had the chance to join the process when the time was right.

        • Aurélien says:

          The first commit in KDE svn for KNotificationItem is from the 19th of February 2009, so I doubt this was in for KDE 4.2.

          Furthermore, Aaron mentions in this post that the spec has been in use since KDE 4.3.

          • J Janz says:

            Well, so that means it *is* possible to implement this as suggested after all, since karmic will use 4.3. That means new chance to do things in a more well designed manner, which is a better desktop for Kubuntu and, by flowing on KDE’s course, collaborates with KDE as a whole.

            • Aurélien says:

              Indicators could be implemented with the NotificationItem spec, provided the spec integrates the necessary features.

              It is not possible in the current state of the spec.

  10. G2g591 says:

    One small correction for you: Arch Linux isn’t source based (Though its quite easy to grab the source if you want to change build options or what not)

    Other than that seems quite interesting and I look forward to seeing this in action in the future

    • Aurélien says:

      I mentioned Arch Linux because I have been talking with an Arch Linux packager who complained about this build-time dependency. When I said it was not a problem for people using binary packages, he told me lots of users were building from source.

  11. frustphil says:

    I think something good is ganna come out of this =)

    For me, I like the idea of indicator applet. But implementing it as another plasmoid is not good because it adds space and confusion.
    For instance one might ask: Where exactly is the notification icon I could click/interact with? My suggestion is to put it beside the (i) icon or just like what alf (the above poster) suggested…

  12. whilo says:

    I am the author of Incoming Message, and it actually was created by me, to allow me to see if there are new messages in relevant apps on the plasma screensaver, so i don’t have to unlock it. Thats about it and it is not supposed to be a notification system. In fact it should show only the information if i need to unlock and not leak any privacy.

    • Aurélien says:

      Oh. I didn’t know it was developed for this use case. I guess it explains why it looks a bit weird when put in a panel:). Still, I think this plasmoid could be implemented with libindicate-qt, it would make the code much simpler.

  13. dipesh says:

    “libindicate-qt depends on libindicate. libindicate used to depend on GTK+ at runtime, but it’s not the case anymore.
    It still depends on GTK+ at build time”

    classic showstopper.

  14. Thomas Zander says:

    I also worry about the reinventing of the wheel without talking to the actual stakeholders here. Thats not how to get results..

    But lets ignore that for a moment.

    I notice you use Qt style C++ api that has a name starting with a ‘Q’. Please don’t do that. Thats asking for trouble.
    Your class should have another name to avoid people thinking its one from Qt itself. Also imagine the problem of Qt shipping with a class of the same name.

    • Aurélien says:

      Mmm true. That’s a problem. Would QtIndicate be appropriate? or should we go for IndicateQt?

      • Thomas Zander says:

        Why do you need a ‘Q’? Make it ‘C’ for Canonical or something like that. Like KDE classes start with ‘K’ and KWord classes with ‘KW’.

        • Aurélien says:

          Because they are Qt bindings to a C library named libindicate. I could use Indicate, but I thought it was a good idea to use a Q to imply the library is QObject-based.

      • Esben Mose Hansen says:

        Namespaces are for solving issues like that. So use e.g. libindicate as the namespace and Indicate as the class name. Qt doesn’t use namespace due to old age; all modern libraries should.

Follow

Get every new post delivered to your Inbox.