Ubuntu Jaunty and the new notification sweetness
Just updated my desktop to the Jaunty beta and i’m really happy with how good everything works.
The extra eye-candy of the new notification system looks really impressive and does enhance the overall feeling.
What somewhat took me by surprise, is the path Ubuntu devs have taken with the notification boxes that had action buttons in them. Behold!
Old pre-jaunty version:
New, “sorted out” version:
What strikes me particularly, is why was it not possible to keep the old behavior for these cases. Especially since not every monkey is running bleeding edge.
Update: In TRUNK we now perform check for action support before trying to add them.
The point is that you shouldn’t not force anything but first ask (via DBus) wether current notification system is able to handle actions. I think org.freedesktop.Notifications.GetCapabilities is what you’re looking for.
Why write a new notification daemon if you could simply write a new engine for the old one with much less hazzle while offering the same bling.
But hey, we are Ubuntu, resistance is futile, upstream does not exist!
oh i bet they had their reasons, just wondering if maybe they could have given some grace period in which both ways would work, instead of just chopping of the head
I’m afraid that Ubuntu have not thought this one through. They said “let’s get rid of all the features (actions, timeouts), and we’ll patch everything that breaks”. Turns out they will have to patch almost anything.
Thankfully gnome-stracciatella-session allows you to use a proper notification system, but it doesn’t get rid of the other crazy patches (like gnome-mount showing dialogues when unmounting stuff).
Thanks for pointer to stracciatella, Bruce!
Alexandre – thanks for suggestions, did that and the fix is commited in trunk now.
Yeah, as far as I can see, the options are:
1) Don’t use actions in notifications at all on Jaunty (or where they’re otherwise unsupported)
2) Have all your notifications with actions automagically turned into modal dialog boxes by notify_osd.
3) Nope sorry, that’s it, there is no option 3.
I’m not sure that I agree with the reasoning behind this – it seems like the main effect of this will be lots more modal dialog boxes in Jaunty – which I wouldn’t see as a win for anyone.
“Why write a new notification daemon if you could simply write a new engine for the old one with much less hazzle while offering the same bling.
But hey, we are Ubuntu, resistance is futile, upstream does not exist!
”
If you look at the source for notify-osd, it is Beautifully simple. Modifying notification-daemon would probably take more work and wouldn’t really afford any special benefits. Dbus allows different notification daemons to be swapped easily at any time, and from the looks of it makes it pretty easy to build one.
The fallback is odd. The main intent there is to be so horrible people file bug reports.
I’m HOPING they’ll at least get rid of the stupid Cancel and OK buttons for the final release, if not set appropriate window hints so the thing actually does what it’s meant to, since end users shouldn’t have to care. We’ll see…
And no, this is not just for Ubuntu! This is about making notifications behave properly. As they are today, the things act as glorified dialog boxes when developers are too lazy to figure out how to make windows appear always on top or think it’s somehow their job to manage windows.
Notify-osd is an attempt to purify that piece of the user interface. This only makes it more powerful for users and developers as we can better tune things to fit smoothly. Now there is (as notification-daemon originally intended before people swamped it with junk) a way to present a passive, unobtrusive notification bubble. Because we can now trust the notification daemon (notify-osd) to be unobtrusive for the platform at hand, notifications are inexpensive.
For upstream, this “bother” is just regular bug fixing. The notification system is meant to be portable, and people are meant to code defensively when they use it (check capabilities!!). It is meant to be used for passive notifications. In this way, it SHOULD be possible to just dump a desktop app on, for example, a handheld and have the notifications it generates nicely presented on that device – for example, with a ticker to the bottom of the screen.
As Jaunty is showing us, that is not possible, which defeats the purpose of the notification daemon entirely.
This assumes that there is no valid middle ground – that you either have passive notifications or on-top popup windows and nothing in-between. The new notify-osd enforces this assumption.
The fact that the old notification demon was hacked by popular demand to support actions – and that everyone then started using them, indicates to me that this assumption is flawed. People obviously wanted a third option – non-interrupting notifications with optional actions. People wanted it so much that someone went to the trouble of coding it up and then loads of apps took advantage of it.
Yes, people should be coding around optional parts of the fdo notifications spec, that’s fine – file upstream bugs then. But completely removing support for notification actions – and then replacing them with semi-modal alternatives doesn’t strike me as a very good move. This flies in the face of rough consensus and running code, which was what we had before.
I’ve yet to hear any concrete arguments as to how this ’solution’ makes things better – or any non-theoretical problems with notification actions; real, actual problems that taking away notification actions by default solves, not hand wavy UI purity stuff.
But notification-daemon’s bubbles WERE on-top popup windows, visible on all desktops and often only dismissed by clicking the Close button! The only difference is they were a bit more compact, had fancy skins, stuck to a corner of the screen and were difficult to respond to using the keyboard.
For notifications with actions that demand response or require to be seen (eg: sticky keys), we have a wonderful tool called GTK. The rest is the window manager’s job, and so far no desktop window manager has really done anything profoundly interesting for presenting popup windows. (Maybe MacOS). Perhaps that’s a place to innovate.
I personally love the new notification system. I actually feel like it does what it was meant to do, meaning to just notify and not get in the way. The only thing I liked about the old notifications system is how well the notifications worked with timed actions.
I do not understand why they cannot build that into the notification system now. Rather than disappearing, the notification bubble can fade pulse a brighter color or keep it the same as before with a timer to bring attention to actual action buttons. Anything is better than the ugly boxes that come up. They really look confusing. As someone said above, action notifications is definitely a place that can be innovated.
One step forward, and one step backward. Let’s make sure to take two steps forward next time. All in all I would prefer to have a fallback to the old notification system for actions until this is worked out. They worked beautifully. Love they new notes feature by the way. Almost perfection you have here.
It’s also dissapointing that:
– You can no longer specify where on the screen your bubbles are placed
– No more than one bubble at a time – if 20 notifications happen, it takes a long time to get to the last one. They used to stack up neatly.
– You can no longer close bubbles manually if you want rid of them – making the previous note that much more painful
Jeremy
* the first bit is something you really should not be able to do (ah, i mean, c’mon, it’s only notifications)
* there can be more than one bubble. 20 notifications? what are you doing there – sounds like killing kittens to me
* you can’t close because otherwise that’s what you would be doing all the time. This new change adjusts your trained behavior (i have that too) to dismiss messages, and that’s a good thing because now you have a one conditioned response less.
Lastly, this post is about grace periods, not the notification system.
This may seem like a weird request – but I’ve been a linux user for 10 years, and I’ve installed Hamster to my panel and can’t figure out how to start the program. I’m using Ubuntu 8.10 and all adding Hamster gave me was a “No Activity” box on the panel. Left click gives you nothing, right click gives you only preferences and panel admin. Super+H gives me nothing. I’ve tried to assign it to other keys – nothing works.
I’m sorry – I just don’t get it, I’m a developer and I can’t figure out how to start your program. Any insight would be wonderful so I can use it.
well just clicking should have brought up the main dropdown as you can see it in screenshots.
this would be the first report of that not happening, so, errm, i don’t know, maybe try to remove it from panel, kill any python instances running around and try adding again.