Ubuntu and Desktop Notifications

This past Monday, Mark Shuttleworth wrote about their plans for an overhaul of desktop notifications (the little popup bubbles telling you someone IM’d you or there’s updates available). Many people have asked me about this, some concerned, and wanted to know what I thought. Being the maintainer of libnotify, notification-daemon and the Desktop Notifications specification, some people were concerned that this work would supersede my own.

The reality is, this isn’t a replacement of my project. This is a new joint effort between Ubuntu, KDE, and myself. What’s been written in Mark’s post may not end up being the end result. We’re still deciding how this will progress, and Ubuntu wants to experiment a bit. Aaron Seigo’s post on the subject sums up a lot of my thoughts on this, and I recommend reading it, though I’ll go further and discuss where this all started and how it’ll affect the project.

First of all, libnotify/notification-daemon isn’t going anywhere. It’s not being replaced, nor is an alternate spec being drafted. Ubuntu’s User Experience team has some new things they want to try, and that’s fine. The plan is to see how this stuff goes in their codebase, with the intention of migrating code back upstream.

A couple of weeks ago, during the Ubuntu Summit, I was invited to speak with some of the developers and User Experience guys from Ubuntu about their plans. They showed me the mockup that’s on Mark’s blog and told me about their plans. They have things they want to do that could definitely improve the experience. Some things are pretty controversial, such as the removal of actions on notifications. We sat down, discussed and debated various aspects of the proposals for a while, and I believe reached a general course of action for the project. The highlights include:

  • Actions will be removed for applications packaged in Ubuntu. The developers will try to replace them with something that they feel makes more sense, with the hope of pushing these changes upstream.
  • The released notification-daemon will, I believe, support actions, since many non-packaged applications do use them. They will, however, appear as old-style notifications and not appear in the new window stack demoed in Mark’s blog post.
  • We’ll be drafting new additions to the notification spec in order to address the needs of KDE and Mozilla.
  • The work will be done by their developers in either a fork or a whole new notification-daemon implementation, allowing them a greater ability to experiment. These changes (or parts of them) will make their way upstream. It will be spec-compatible so users won’t have to worry too much about losing features (aside from actions, perhaps).
  • In the end, it’ll likely be that the Ubuntu theme specifically works this new way, and that other themes will work differently (they may support actions more directly, for example).

Now I should point out that I don’t believe actions are a bad thing. There’s many use cases where actions are very much warranted, and it seems Aaron agrees. While the Ubuntu team has discussed the possibility of deprecating this in the spec, I believe the end result will be that actions will live on. I’m also pretty adamant that upstream notification-daemon will still support actions and some other features. Ubuntu can choose what experience to give their packaged applications, but that may differ a bit from what we decide upstream.

Time will tell how this all turns out. I personally think it’s great that there’s some momentum on this project. I know I haven’t had much time to work on it as of late, between VMware and Review Board, which is why getting some new people on board with fresh thoughts will probably be a good thing.

On a related note, I’d like to welcome Andrew Walton to the project. He’s going to be working as a co-maintainer and helping out when I’m busy (which will be a lot of the time for a while).

Over the next month or two, the project should start to pick up. We’re beginning to look at ways to improve the spec and at what work needs to be done in the near future for the project. These discussions will take place on xdg-list.

And with that, I wish everyone a Merry Christmas (or just a very good December 25th for those who don’t celebrate Christmas)!

libnotify 0.4.5 and notification-daemon 0.4.0 released

It’s been a long time since I’ve really put out a libnotify or notification-daemon release. Review Board and VMware have taken up a lot of time the past year, so development has been slow, but I think these releases are worth it.

libnotify 0.4.5 [Release Notes] [Downloads]

This is mostly a small bug fix release, but introduces support for associating a notification with a GtkStatusIcon. This allows for better position tracking when notification icons are jumping around.

notification-daemon 0.4.0 [Release Notes] [Downloads]

This is a large feature and bug fix release. The major two features are multi-head support and a new control panel applet for specifying the notification theme and corner origin.

The multi-head support will show standard (non-positioned) notifications on the monitor the mouse is currently on. Previously, they would only appear on the primary head. This helps to notice new notifications, and fixes problems with some people who have a multi-head setup but only have one monitor on or in view. Also, notifications that appear on the edge of a monitor in a multi-head setup will no longer cross the monitor boundary, and will instead just stay on the correct monitor.

The new control panel applet makes it easy to switch notification themes or to specify which corner notifications should appear from. This will be expanded in the future.

As mentioned above with libnotify, notification-daemon can now track when status icons have moved so that the notifications are no longer in the wrong position during startup.

There’s a bunch of other nice little bug fixes that are mentioned in the release notes.

Thanks for the patience, everyone!

Transparent notification screenshots

In my release announcement for the new libnotify and notification-daemon, I advised that people try the new release in order to see the transparent notifications for themselves. This was obviously a mistake as many people wanted to see screenshots. Silly me.

I guess I thought that this was one of those things that looked better in person than on a screenshot. I was also a bit tired and busy with other tihngs and didn’t want to put in any more effort. So I took a couple and hey, it looks pretty good anyway. My apologies. I should have done this last night.

New libnotify and notification-daemon releases are out!

I’ve just put out libnotify 0.4.4 and notification-daemon 0.3.7 releases. I highly advise that everybody upgrades, as several memory leaks, rendering glitches and other bugs have been fixed.

Along with these releases is some basic support for accessibility in the notifications and a nice, subtle transparent effect on the notifications when running on a system using a compositing manager. Don’t worry, it’s not bad at all, and it doesn’t make the notifications any harder to read. I’ve been running this for some time at this point 🙂 I would show a screenshot, but it’s probably best to see it on your own setup.

The downloads are available on the downloads page, and full release notes are below:

libnotify 0.4.4 changes

  • Fixed a bug where a notification’s ID could be reset when a different notification was closed. Patch by jylefort. (Bug #94)
  • Fixed a crash when the D-BUS proxy was not being freed on notify_uninit, which was problematic when used in a loadable module. (Bug #92)
  • Fixed a crash when a signal handler for the notification’s closed signal caused the notification to be destroyed. (Bug #116)
  • Fixed memory leaks when creating notifications. (Bug #112)
  • Fixed potential memory leaks where the function passed to notify_notification_add_action to free the user data was not being called. (Bug #119)

notification-daemon 0.3.7 changes

  • Fixed a compatibility issue with dbus-glib 0.72. Patch by Pawel Worach. (Bug #95)
  • The background of the window in the standard theme is now just slightly transparent when compiled against GTK+ 2.10 and when using a composite manager. Patch by Matt Walton. (Ticket #110)
  • Fix several rendering glitches with the borders in the standard theme.
  • Fix a memory leak when removing a notification. Patch by Sven Wegener. (Bug #105).
  • Added initial accessibility support with the standard theme engine.
  • Clicking anywhere in a notification should now close the notification. This was happening only on the body text sometimes.

libnotify 0.4.1/0.4.2 released

I just put out a release of libnotify 0.4.1. It has support for the new GtkStatusIcon (when compiled against GTK+ 2.9.2 or higher) and the documentation has been moved over to gtk-doc, so if you compile libnotify with –enable-gtk-doc, you should see a new “Libnotify” book in devhelp. There’s also a bunch of bug fixes too. Release notes are available.

I have some nice fixes and feature enhancements planned for notification-daemon that I’d like to get to before long. Some optional window slide-in/out or fade-in/out effects for the notification bubbles, maybe a new theme, and better notification placement.

Update: libnotify 0.4.2 is now released, with a G_BEGIN_DECLS and G_END_DECLS in notify.h so that deadchip can make C++ bindings. Woot!

New libnotify, notification-daemon and notify-python releases

I’m very tired, so I’ll keep this brief.

I just put out libnotify 0.4.0, notification-daemon 0.3.5, and notify-python 0.1.0 releases. Most of the really annoying bugs people have reported have been fixed. More information is available on the news post.

I made a decision that will be unpopular to some, and I expect some disagreement on it. notification-daemon 0.3.5 does not ship with the Bubble theme. A large number of the problems people have reported to me on IRC and in e-mail centered around this theme, and until I have the time to give it the attention it needs, I’m removing it from the default install. It’s still in SVN and the tarball, and development will resume on it at a later date. However, I want to give people the best out-of-the-box experience as possible, and the Bubble theme currently makes that hard. If people want to chip in and help, you’re more than welcome.

Aside from that, it’s a very good release and I highly recommend people update. As always, please make sure to report bugs.

I have a couple of neat things I plan to work on. One is a little event notifier for scheduled events on online calendars (30Boxes.com to start). This will be using the new libnotify Python bindings. If it proves useful, I hope to add Google Calendar support as well. I’ll make some sort of announcement once I get a prototype working.

I Can’t Believe It’s Not Chicken, now in gelatin style

Something I threw together the other night in Inkscape


I finally gave up with the whole “playing everything politically safe” with Galago and am now moving the whole library to GLib. It’ll take some time, and there’s a few things I need to figure out first. For example, a very useful feature that Galago’s object model let you do was connect a signal handler on a class itself, which would call the handler any time the signal of any object of that class was emitted. This of course didn’t translate to other object models or bindings well, and certainly doesn’t translate to GLib at all.

One of my potential solutions was to create a Manager class for each class where developers would want to do this. The Managers would be singletons and objects would emit signals on them as well as themselves. Maybe Manager is a bad name of the type of object… I’m still not sure what to do about this. It’s a very useful feature though, and the only alternative for everything that currently uses this is to set up a bunch of signal handlers for parent containers to know when these objects are added/removed and then register/unregister signal handlers every time the objects of interest are created/destroyed. It’s a lot of messy code, and would take up more memory than a manager interface. Still got to play around with the idea more…


I’ve begun work on porting libnotify and notification-daemon to D-BUS 0.3x. I plan to use a simple abstraction layer consisting of macros to keep compatibility with D-BUS 0.23.x for now. I have a lot of work to do this week at VMware, so I don’t have a whole lot of time to devote to it right now.

Mike Hearn and I had a talk earlier about extending the notifications spec. Sorry, we’re still not going to provide a way to embed Mozilla. One thing people have been wanting, though, is to be able to associate a notification with something on the screen, say, a notification icon. So what we’re going to do is provide support for X, Y coordinate hints. Since they are hints, the renderer will be able to just ignore them if they want. However, this would allow the battery applet (for example) to say, “I have a notification, and here’s my location!” and the renderer could pop up a notification near there with, say, a little arrow pointing to that X, Y location. This could be useful in a few situations, though hopefully it won’t be abused.

I have some future plans for the notification daemon. I’m going to put together a (for now at least) experimental daemon that has two types of plugins: Render plugins and Transition plugins.

The Render plugins will be responsible for rendering the notification. They could do the nifty folding thing that appeared on Planet GNOME a while back. They could do a bar sitting at the bottom of the screen, semi-transparent. They could do toaster popups. Whatever.

Transition plugins handle how the notification will be displayed. They could just show a notification, fade it in, slide it in, make a poof of smoke.

Again, it’ll be a while before I can start on this, due to life just being busy right now.


And this is one other reason why life is busy. My girlfriend Jamie and I are going with my family to Disneyland after next week. Unfortunately, this week is spent on some deadlines at work. But that’s just going to make the next week even more fun 🙂 We’re staying at the Disneyland Hotel, which will be a first for both of us. I’ll have plenty of pics when I return.