Created attachment 197937 [details] [review]
messageTray: Add new API for notifications that want to auto-expand

Some clients mark their notifications as URGENT for the sole benefit of an
auto-expanding notification, without wanting any the other behaviors. Add
an explicit API for these clients.

Created attachment 197938 [details] [review]
autorunManager: Use new Notification.setAutoExpand API

Instead of marking ourselves as URGENT, use the new setAutoExpand API so
that users don't have to click on our notifications to dismiss them.

If I remember correctly, the reason to mark automount notifications URGENT was less to get autoexpanding, but rather that it provides more functionality than the summary notification (e.g. a list of supported actions rather than only one).

A couple of points:
- the physical machine could not be immediately accessible to the user when plugging the removable device, e.g. it could be a workstation under your desk and some time might pass between the moment you plug the device and the time you're actually able to act on the notification (or you might even miss it). That's mostly the reason it doesn't time out automatically IIRC.
- an orthogonal approach that was proposed for this is having an explicit Close/Cancel button on the notification itself, so it's clear to the user how to get rid of it. If we wanted to go down this way, we should probably do it consistently for other notifications as well, even though it is somehow mitigated by the notification hiding away when it's not urgent.

I can see how the current behaviour could potentially be annoying if you already know what you're looking for, e.g. when you have an app already focused (say, GIMP) and want to open an additional file from the removable device, but have no strong opinion on the approach of this patches.

CC-ing Jon: what do you think?

Created attachment 198572 [details] [review]
messageTray: Add new API for implicit URGENT properties of notifications

Some clients mark their notifications as URGENT for the benefits of an
auto-expanding notification or one that doesn't timeout. Allow clients to
control these properties individually instead of an "all or nothing"
approach.



--

I still don't think setting URGENT to get the properties of an URGENT notification is the correct thing to do. Unless we want automount notifications to take priority.

Created attachment 198573 [details] [review]
autorunManager: Use new Notification APIs

Instead of marking ourselves as URGENT, use the new APIs for
notification properties so that these don't block normal notifications.

*** Bug 662428 has been marked as a duplicate of this bug. ***

I ran into this auto-expanding behaviour with two notifications, which have been those. Let me first explain why I personally didn't find them useful (while other users MAY find them very useful, just for demonstrating that not everyone might be interested in them):

- Mount notification when plugging in an usb stick. Highly disruptive because a) I know I just plugged in the usb stick (informative value: zero), b) I wanted to use it later but not instantly (therefore practical value of the offered buttons for instant use: zero)

- System update notification: I always use yum update because yum is slow enough without a GUI. Additionally I often turn my computer off or do things where I require more cpu since the machine is quite weak (netbook), therefore I often don't want to update right away but when I have the time for it and don't need the machine for other intensive tasks.

Now of course the missing timeout of those notifications (as described by this bug) is annoying, but I have another issue with it that isn't discussed here:

Why do those notifications need to be auto-expanding at all? Expanded they are huge on netbooks, and that is pretty huge for notifications I don't care about. Others might care (I am not questioning that those notifications ARE possibly useful to some users) and can just move the mouse down there. But why auto-expand them right from the start at all and annoy the users that don't care?

> - the physical machine could not be immediately accessible to the user when
> plugging the removable device, e.g. it could be a workstation under your desk
> and some time might pass between the moment you plug the device and the time
> you're actually able to act on the notification (or you might even miss it).
> That's mostly the reason it doesn't time out automatically IIRC.

So what about timing it out when the user is clearly not idle (has used mouse or keyboard since notification appeared or since stick was plugged in) and otherwise keep it on screen forever?

Given urgent notifications are generally really urgent (major sytem failure or whatever else it might be used for) and should be really seen and noticed by the user, this would be probably the best idea (while still making them less annoying).

There should probably be an exception for movie player detection so that it doesn't obscure the screen forever when you watch a movie but don't actively interact with the machine, if something like that is technically possible (I guess most movie players deactivate screensavers when they're running, so that might be a helpful indication for such a case).

Perhaps there should be an icon that opens an history of former displayed notifications?
My father has an androphone (sony xperia) which has a notification area that displays missed notifications by sliding a bar located on top of screen.

*** Bug 677285 has been marked as a duplicate of this bug. ***

*** This bug has been marked as a duplicate of bug 657923 ***