The message tray in GNOME Shell enables persistent notifications. A new notification is first shown as a pop-out for a certain time period. When the pop-out is hidden, the notification is still available to the user in the message tray. The notification is only removed when the user interacts with it or switches to the application that sent it. This default persistent behavior ensures that the notifications are less disruptive to the user because the user is no longer forced to react to them before they time out.
Before the holidays, I finished implementing support for two other types of notification behavior: resident and transient. Resident notifications are available to the user even after the user has interacted with them or with the application that sent them. On the other hand, transient notifications are not kept around for the user at all after they are initially shown.
Jon McCann has updated the Desktop Notification Specification to expose these new features to applications. The “persistence” capability advertised by the notification server means that the notifications are persistent by default and that resident and transient notifications are supported. “resident” and “transient” hints on the notifications are used to mean that the notification should be resident or transient.
Resident notifications often go along with rich controls in notifications. Rhythmbox notifications are a good example. During his GSoC, Matt Novenstern came up with a way of specifying icons to be used as notification’s actions, enabled this feature in GNOME Shell, and wrote a patch for using icons for the playback buttons in Rhythmbox notifications. Jon has updated the Desktop Notification Specification to reflect this feature. When the notification server has the “action-icons” capability and the notification has the “action-icons” hint set, named icons that match the action identifiers are used for the notification’s action buttons.
Putting it all together, Jonathan Matthew has reviewed and pushed Matt’s patch for playback icons and made Rhythmbox notifications resident. Resident behavior of Rhythmbox notifications allows the user to see what’s playing and use the playback controls at any time. Incidentally, Jonathan has also worked on the GNOME Shell side of things, coming up with the initial patch for the resident notifications support.
Empathy chat notifications are also resident in GNOME Shell. Because they allow chatting inline in the text entry field they contain, making them resident enables the user to continue a conversation at any time.
The resident behavior and rich features of Rhythmbox and Empathy notifications help minimize the distraction from intermittent events. They allow the user to react to such events at the user’s own convenience and without switching away from the window the user is working in.
Applications should use resident notifications if they are so heavily notification based that the user would expect to see a notification in the tray most of the time and use the application by interacting with its notification’s rich features. In this case, the user should be able to reliably find the notification and not have to guess if there is one in the tray or not.
The other new type of notifications, transient notifications which don’t stay around in the message tray, are mainly intended for use by the system components that have a permanent representation elsewhere, such as in the system status area in the top panel. For example, non-critical battery information notifications are transient.
Transient notifications can also be used as a feedback for the user’s action within the system. For example, they are used when the user adds or removes a favorite application in the Activities Overview mode and allow undoing the action.
Persistent and resident notifications enable complete interaction between the user and the application using only notifications. In GNOME 2, authors would use GtkStatusIcon to anchor the information shown in the notifications, but this is no longer necessary and the applications should move away from the GtkStatusIcon usage. The suggestions for individual applications and system components can be found in these compatibility guidelines. Please find us on #gnome-shell IRC if you would like to discuss the use of the notifications by your application in GNOME 3 or help out with the message tray features.
Very good job.
But…
This system of notification, it it reinvents the actually systray. No?
another reason why i should switch to shell squashed. this looks damn beautiful
just my 2 cents. if i misunderstood please ignore it like i said nothing
i hope you don’t make the same mistake as android which is overusing persistent notifications. if you update 20 applications or so you get 20 persistent notifications for each application and they don’t disappear if you ignore them. even persistent should have some sensible timeline or at least be stacked into same group. android for example creates one icon in tray for every persistent notification making it really cluttered as soon as you end up without space to show additional notifications. in one of updates they finally added “clear all” (android 1.6 on my previous phone), but before that i simply turned phone off and on to get rid of that nonsense. it was still faster than interacting with every notification to get rid of the clutter. and that is installing only. i don’t even wanna think about other applications.
please, don’t take it as criticism, it isn’t. damn thing looks beautiful. problem in this always arises from the fact that every coder seems to think that his application is so great it has to do persistent notifications and this always leads to clutter. if notification interface doesn’t do sensible prevention of that fact… you simply end up where every other notification system was. one big pile of mess
another 2 cents of mine
some applications like media player, messaging and so on should never ever do persistent notifications. it would be much better to have widget layer in gnome shell which covers full screen and there you set up your widgets like you want them. media control (click and if your favorite media app is not yet started it starts it, otherwise it simply acts as simple remote control), same for messaging and other tasks like that. by having access to that layer from shell and with shortcut i can’t see anyone losing. the removing from favorites is the same. why require from user to interact twice with same action, much better option would be log like feature where each action imposes undo option. as implementation you could simply imagine gdesklets, screenlets or any kind of widgets done full screen. press shortcut and widget screen slides over your desktop, press escape and it slides away.
Nice!
But I kind of disagree to make “old” notification persistent by default. In the way those where used/abused by default I would rather have those transient by default and fix those applications that really need persistent notifications!
Very good but I think there’s still room for innovation. Like what happens when you’ve got 2 or 3 notification heavy applications running? They notification system’s goal of being unobtrusive might go away. It could be fixed with some kind of horizontal stacking… just thinking.
Anyway, good job.
The new expanded hints of the 1.2 version of the spec I see there are quite interesting indeed, especially the “transient” and “resident” flags.
In KDE we are doing a similar thing since quite some releases: an history of old notifications for further consultations (and i’m happy a similar approach has been taken by you guys as well, kinda validates the idea more).
This at the moment doesn’t touch the notification spec but stores instead all notifications. This is not optimal for sure, I have some doubts about trusting the applications to do the right thing tough.
This is an issue that can be sorted out (and the new spec is worth to be tried for sure)
What however i’m not impressed with, is the updated and the expansion of a freedesktop spec without passing from xdg at all (last message i see there about notifications is december 2009). The link is in a people.gnome.org page: is it still a draft, have it been published or what?
The notification system is a really important piece of the cross desktop integration, since what an application says could be displayed by a gui of the other desktop, with potentially very different paradigms.
So I espect notification from an application of the other desktop to be as functional as possible (or a much as the different ui paradigm permits)
From old messages in the xdg mailing list, we can see the life of this spec has been quite challenging already (we can still hear the echoes of the war on action buttons)
So please, it is important this gets agreed upon, bring it over to the xdg mailing list (that is working less and less, this ought to be fixed) and let’s agree about what’s needed in the new expanded version.
@korbe, @anonymous, @Johannes, @Paul-Sebastian Thanks!
@korbe We now only have selected system status indicators in the top bar, such as network, power, volume and accessibility. The notification-based representation in the message tray is a better fit for most other types of icons that used to be in the system tray, such as chat, music and software updates. You can find more information about the design here: http://live.gnome.org/GnomeShell/Design
@anonymous, @Paul-Sebastian The notifications are grouped by application. We only show one latest notification right now, but I’m planning to work on showing a combined view of multiple unacknowledged notifications from an application in the summary view next.
@anonymous We would like the user to interact with applications directly and their notifications, but do not want to make the interaction options more complicated with new options like widgets.
@Johannes The goal is for the user to not have to chase any notification, so unless it is completely fine for the user to miss it, it should be persistent by default. Of course the applications should use the notifications judiciously. We have some guidelines for individual applications here: http://live.gnome.org/GnomeShell/Design/Guidelines/MessageTray/Compatibility
@Marco Martin Thanks for the feedback. The notification specification document has been mainly updated by Jon McCann. This is why I’m linking to it on his people.gnome.org page. It is also maintained as part of the libnotify library: http://git.gnome.org/browse/libnotify/log/docs/notification-spec.xml I’ll pass on your interest on collaborating on it to him.
I’m really excited to see this in action.
lol, i didn’t said notifications should go into widgets. i tried to say some applications shouldn’t go into notifications. if they want to expose something some kind of widget layer would be much better suited for those. i’m sorry if i worded it badly.
sorry, i pressed submit by accident.
showing last one only >>>> heaven on earth
what if multiple notifications show up at the same time, one of them has input and i write in it? it moves around? i get a stockpile of notifications growing and growing?
With the relayout design and the explanation of how the notification system works, I’m more than convinced that I Gnome-Shell is the way to go.
I really like the way it combines ideas from MeeGo, some hint of Unity, and even KDE, and still it’s unique.
And as far as I can tell, it seems more touch friendly.
Just one idea that I don’t know if it is, or will be implemented: a device handling indicator on the top bar, similar to KDE’s or MeeGo’s implementation, or a combination of both topped with the magic of Gnome-Shell would be even more awesome.
Notifications were a big problem in Gnome 2. With your work, seems tha in Gnome3 we will have a very beautiful notification system.
The only big problem (for me) in Gnome 3 is Gnome-Shell: will not be integrated with the look of applications (as far as I know), and is very ugly (very bad designed, is not intuitive). However, things like this promising notification system and other many things make that people like me have our hopes in Gnome 3.
I’d like to highlight one issue with using the notification area, bug #630842.
Essentially, when something has an old-style exported windows, the icon is clickable, but the generated text is not. When you mouse down to the area to see it, the clickable area actually moves out from under your cursor when you go to click on it.
This begins as tragedy but devolves into comedy pretty quickly. 🙂
While I understand the issues involved (simulating events), it’s also possible to hack it to be less evil by simply reversing the label and the icon so the clickable area doesn’t move.
I think what Marco was trying to say is that Jon McCann should never have just ‘updated the specification’ – it’s a standard, you can’t unilaterally change it. He should’ve contacted the people who have been involved with the standard (Ubuntu and KDE, maybe more) and discussed it with them 😉
> you can’t unilaterally change it
well, you can. Jon did. what it results in is refragmenting the Linux desktop space, both in practice (we are no longer compatible) and due to social reasons (why both trying to chase what Jon evidently perceives as “his” spec?).
we’ve worked so very hard for many years to bridge gap after gap, including making compromises so that we could achieve the goal of unified behavior between applications from different project groups.
this really undermines that. so while you _can_ do things like this, it’s a step backwards. this is really unfortunate because in this case it’s probably an improvement. and instead of all of us being able to cheer on the work of Marina, there’s this “oh damn” result instead.
Marina: the stuff you’ve done looks really nice. 🙂
I am REALLY happy that this stuff has made it to a specification. However, I think it will be a good idea to actually have two parallel notification systems, where one of them has this stuff in it.
Ubuntu is on to something with notify-osd. It makes sense in its own right, particularly with the added synchronous notifications for volume and brightness feedback. Perhaps the persistent stuff can be split from the transient stuff, called something different, and everything will be shiny and happy.
This happens with Toast Notifications vs. Status Bar Notifications in Android:
http://developer.android.com/guide/topics/ui/notifiers/index.html
You’ll find that same kind of design in many modern platforms.
With the implementation of this (so far) in Gnome Shell, I’m concerned that I need to click a notification — or at least scrub over it — to get any meaningful information beyond that a notification exists.
Android and WebOS both run on smartphones with 3-4 inch screens, and they make wonderful use of space. In Android, you almost always see an icon for every notification at the top left of the screen. You just need to swipe your finger once to see everything there is to know about every notification (including its description, progress bar, a nice picture, etc).
Now, on a 14-24 inch computer monitor, you need to first expose the message tray. Then you need to click each notification, one by one, to get the same kind of summary you get at a glance on a tiny phone.
Unfortunately, I can’t think of a particularly elegant solution that still uses the (quite awesome) message tray concept, but I’m sure there is one. Maybe each notification can be given some fixed horizontal space for dynamic information; something like the current window list (but prettier).
Good luck! 🙂
Macro, Jos, Aaron: Agree with your points (changes should be discussed). Fully agree to work together. I want to check what happened with those involved. Position from GNOME release-team regarding freedesktop and working together has not changed.
Marina: Apologies for going somewhat offtopic on your blog.
Aw, thanks for the mention, Marina! The notifications are looking good!
@saikobee, @Bla bla bla, @Aaron Seigo, @Matt Novenstern Thanks! And @Matt Novenstern thanks for your work on this ;)!
@anonymous Yes, I understood you correctly about using widgets instead of some notifications, but what I said is that we only want to have applications and notifications, and not add other types of things for the user to interact with, such as widgets.
@bombo New notifications show up one at a time. As long as you are interacting with the notification that is showing, we queue the rest. You can move on to the next notification by clicking Esc or (soon) the Down arrow. We’ll eventually have an indication that more notifications are being queued.
@zsoltsandor The system status indicators in the top bar include the one for Bluetooth:
http://live.gnome.org/GnomeShell/Design/Guidelines/SystemStatus/Bluetooth
Other devices, such as USB sticks, will be represented in the dash (left vertical panel) in the Overview and their detection will possibly be accompanied by notifications.
@Bla bla bla The described notification system is one of the integral parts of GNOME Shell, and the rest of it might be better than you think :). If you haven’t tried it lately, building the latest version with JHBuild might be an interesting thing to try:
http://live.gnome.org/GnomeShell/#Building
The design is explained here:
http://live.gnome.org/GnomeShell/Design
@James Cape We are holding off on fixing this bug because we’d like to focus on what is causing it, which is accommodating the legacy GtkStatusIcon(s) in the first place. We hope to have a lot fewer of them by the release of GNOME 3 and at least not have them for the core GNOME components and applications. I’m also going to try to make the accordion affect feel more stable soon by adding a timeout for the expansions and not collapsing the left-most item when you move past it to the left.
@jospoortvliet, @Aaron Seigo I see what the situation with the spec is. The changes, which are all optional extensions, were added as work-in-progress to accommodate the design of the message system in GNOME 3. As @ovitters says there is interest in the GNOME community to work on the common spec.
@ovitters Thanks for voicing the position of the release team in your comment.
@Dylan McCall The designs of the notification systems in Unity and GNOME 3 are tightly coupled with the desktop environments they are a part of, so they are not interchangeable.
It is a valid point that you need to mouse over to the notification or click on it in the message tray to get all of its content. The upside though is that the notifications are not intrusive, which was a major design goal.