Ubuntu Wiki

Your comments on NotifyOSD are welcome here. Please sign your name with each comment. Thanks!

There are quite a few users who are dissatisfied with NotifyOSD and there's been no Canonical response to demands for more user-friendly, customizable notifications.

NotifyOSD has no functional implementation of the expire_timeout parameter of org.freedesktop.Notifications.Notify. NotifyOSD ignores expire_timeout

This is rather inconvenient, as notifications won't dissappear for several seconds after the user has clearly read and understood the message. It also causes certain notifications to be lost.

The FreeDesktop specifications are by no means perfect; nor are they legally binding, but making unexplained diversions from them is disrespectful, espcecially when those changes break useful functionality.

The arbitrary timeouts (10000ms and 5000ms) specified here need to be configurable, at least as an optional setting through gconf or gnome-appearance-properties. Bubble Behavior

--quequotion

• From the specs , It seems the Default for Evolution is to Not show notifications. What about users who want mail notifications?

• From testing in Karmic , The present mail notification is inconsistent and redundant ,Just reports "N new mail" and sometimes doesnt report the correct number.

• The present notification only shows the number of mails received at the last update , not the cumulative number of unread mails. [which is redundant : User Scenario> user receives 10 mails , has not read them , now after the next update receives 4 mails , new notification says "4 New mail" , instead of "14 New Mail" ! ]

• At minimum, an info about the folder could be added, Ex: if user receives a total of 10 mails , 4 in Inbox , and 6 in a folder labeled "Folder"

If user receives 4 mail only in 1 folder/inbox:

• If user has only single evolution account , [Account name] is not mentioned in the notifications.
• If user has only single evolution account , with no custom folders , then the "in Inbox" is not mentioned in the notifications.
• If user has several folders or accounts and if the New mail has arrived in folders exceeding 10 , the notification is split beyond 10 as a second notification, the next notification should have no header , and lists the remaining new mail folders as the Body of the notification . --mac_v

• I would like the bubble position to be configurable. As you can see from the comments below, different users like them in different places. Karmic uses east gravity, different from Jaunty's NE gravity. Seems I became accustomed to Jaunty. Please make this configurable. -- pmiller
• I find the notification duration too short. Perhapse the display time needs to be proportional to the amount of text? Please make the delay time configurable. -- pmiller
• Moving the cursor over the bubble could keep the bubble open longer, or open until the cursor moves out again. -- pmiller
• a right click on a notification bubble could open a configuration dialog -- pmiller

• What exactly is so exciting about this? How is this better than what existed previously? Maybe I don't understand it, but seems like a whole lot of work for developers for no real benefit. I feel developer time could be used on better things. --SarangKulkarni

Maybe the notifications should appear by default in whatever corner is home to the system tray, which is what the old notifications did. Make it configurable, too, of course. But spare some people who switch up their panels the added step of switching their notifications to match. - Bastanteroma

• I enthusiastically agree with conforming with the behaviour of the old system in this respect. - maxb

I think listing any Kubuntu applications here is premature. There is no buy in at all from the Kubuntu community that these changes are desired - ScottKitterman

• Fair enough, I’ve removed them from the spec. —mpt

I think if Canonical Dx is going to modify Universe/Multiverse packages then they ought to commit to maintain them and not pitch the changes over the fence to the community - ScottKitterman

I find that notifications which warrant acknowledgements - e.g. wireless or battery state changes - appearing as bubbles at the edge of the screen is a much nicer experience (less disruptive) than alert boxes. I think notifications that relate to a panel notification area icon appearing next to the related icon is an excellent feature. For notifications that contain a non-trivial amount of text, I like that they remain visible until dismissed by clicking. I like that I can manually dismiss a notification if the system's idea of how long it should remain is different to what I want. In short, I disagree with large chunks of the rationale. I think there should be an easy way to revert back to notification-daemon on a per-user basis. (Note: not stracciatella, only the notification facility) - maxb

• We agree that wireless and battery state changes are better as bubbles at the edge of the screen than as alert boxes. And we agree that notifications containing a non-trivial amount of text generally should remain visible until dismissed by clicking. So you don’t disagree with us as quite much as you think! stracciatella has a specific use case of allowing use by Gnome upstream developers, but I doubt there’s a realistic use case for allowing per-user toggling just between notification-daemon and Notify OSD. —mpt
  • Why do you doubt that allowing users to opt out of Notify OSD is realistic? It's a pretty huge UI change that users may not wish to have forced on them. -maxb
    • Because it wouldn’t be an understandable choice. We don’t even ship multiple Web browsers or IM clients by default, so we’re hardly going to ship multiple implementations of something as banal as a notification server. It’s not a huge change, it’s tiny relative to the overall interface. —mpt

Having read through the docs covering the NotifyOSD changes, I have to say I'm pretty lukewarm about it, as are a lot of others in the community, I think. From a users perspective, it seems like the end result will be an increase in the number of modal popup dialog boxes in addition to notification popups which now refuse to follow your chosen theme. I wouldn't consider this to be progress, on the whole. Having said that, the persistence (logging) and queueing stuff sound like a steps forward, although they probably won't show up until 9.10. Also, I generally agree with ScottKitterman about community maintenance issues. - DuncanLock

transmission and gnome-mount need to be patched - BUGabundo

• Thanks for pointing them out. They’re both specced and patched now. —mpt

There is an experimental plugin for firefox that uses the notifications for downloads https://addons.mozilla.org/es-ES/firefox/addon/9622 - JorgeCob

• Unfortunately that wouldn’t really help, because it would result in Notify OSD showing an alert box whenever downloads had completed. Our recommended behavior for Firefox doesn’t use notification bubbles at all. —mpt

  • Hello, I'm the author of said extension; just thought I'd pop in and ask if there's anything I can do to help integrate this more with Ubuntu's new build. I think if I fix the one major issue (need to move from binding to the window to an XPCOM binding, I need help doing this if anyone understands what the hell that means (I don't)) it should be ready. I'm only keeping it in experimental at the current time because of that. It seems to me the spec currently describes the default behaviour as FireFox already is, since NotfiyOSD can't have the links to open download window. -- Abhishek Mukherjee <abhishek.mukher.g@gmail.com>

I added gmail-notify to the NotifyOSD page... maybe I did wrong editing it myself, excuse me if I did as I don't know which is the usual process. - Pablo Quirós

I'm a little confused about how this stands compared to the original proposal. I see several references to actions on notifications. Is that part of the proposal changed or is that just for applications that have not been patched not to know not to request actions? From my perspective that aspect of the proposal is extremely troubling and it would be a welcome change in direction if it were to be dropped. - ScottKitterman

• At UDS, Christian Hammond pointed out to us that we can’t do what the spec allows and just ignore actions altogether, because there will be various privately-distributed programs written by people who just assumed notification-daemon would always be used. Using alert boxes for actions avoids those programs breaking completely, and we’ve published NotificationDevelopmentGuidelines on how to migrate to other notification mechanisms. —mpt

Does the absence of Rhythmbox in the list of applications that need patching mean that Banshee is the to-be default player for 9.04? - MichielBeijen

• No, it just means that Rhythmbox wasn’t using interactive notifications. —mpt

What about using NotifyOSD to also show progress of certain things i.e. burning a cd, downloading a file, or eventually also checking mails and similar things? But then the user should be able to hide those messages and he would get a new notification when the action is finished. Something to think about for the future IMO. - MartinJuergens

• Coincidentally, I added a note to the notification design guidelines recently explaining that notification bubbles should not be used for showing progress, and briefly describing what should be used instead. Notifications stay on the screen for only a few seconds, whereas progress feedback might unexpectedly take minutes or hours. —mpt

Why only two? Currently I like the way Gwibber shows its notification: flood your screen with tweet messages (so I patch it to show only 13 message or x new message) in this method, I can read every tweet while working and when I'm very busy, I just turned it off. Also, I use my own program which play song and display its lyric via notification so while I'm working I can sing along the song but when this landed my program'll probably break because Gwibber'll consume all the quota. Should I switch to xosd? - Manatsawin

• This wasn’t a clear-cut decision. At the moment we think that if Notify OSD showed multiple bubbles simultaneously, either they would go away too quickly to read for those trying to read them, or they would obscure too much of the screen for too long for those engrossed in something else, so showing one at a time was better. We could be persuaded otherwise, though. For your lyrics question, that’s the sort of thing that really needs to be synchronous, so asynchronous notifications probably aren’t the best mechanism to use. —mpt

For KDE, do you plan to enhance the existing KNotification implementation in KDE or extend notify-osd to provide an alternative implementation of the API? - ScottKitterman

• We’re in discussions with KDE and Gnome developers on freedesktop.org to come up with a unified DBus protocol, which KNotification would then implement. —mpt

I think it's a mistake to put notifications in the top-right corner of the screen. Useful chrome goes there: toolbars, control buttons on title bars. The bottom-right is typically emptier. I also, somewhat incongruously, think it's a mistake to disconnect notification bubbles from their associated notification area icon. (I'd even go so far as to not display any notification area icon that *doesn't* have a bubble attached to it.) —Greg K Nicholson

• We’ll be reconsidering the bubble position for Karmic. —mpt

I submitted a patch to pidgin-libnotify that fixes a lot of the issues with this. It checks to see if actions are supported before using them, and it puts the names in the title so that you can tell if someone logged in or out. I've been running it all day without any problems. Great job on the new notification system, it's gorgeous. https://sourceforge.net/tracker/index.php?func=detail&aid=2634701&group_id=144907&atid=760303 http://img15.imageshack.us/my.php?image=notifyosdpidgin.png

Having 1000 notifications in queue is bad! 100 and not older then one minute makes more sense. Sometimes pidgin or gwibber dye on me, and 15 min latter I'm still getting indicators show up. --BUGabundo

I totally agree with this comment --

"Having read through the docs covering the NotifyOSD changes, I have to say I'm pretty lukewarm about it, as are a lot of others in the community, I think. From a users perspective, it seems like the end result will be an increase in the number of modal popup dialog boxes in addition to notification popups which now refuse to follow your chosen theme. I wouldn't consider this to be progress, on the whole. Having said that, the persistence (logging) and queueing stuff sound like a steps forward, although they probably won't show up until 9.10. Also, I generally agree with ScottKitterman about community maintenance issues. - DuncanLock"

it does seem taht the no. of although unfocused, popups and alerts willl significantly increase.

PLease someone at canonical tell me if this notification system overhaul was meant to increase productivity of users by not nugging them with popups that needed actions then how do u justify this?

--tgpraveen89

--what about CheckGmail? i use it mainly due to the fact i can delete/archive/open a message from the windows itself, without opening a browser.. --IsraeliHawk (Uri)

I agree with the reasons of the changes, but they are somehow too radical. The interaction was often useful (for example to open incoming mail, IM, etc., there is no nice alternative that would be connected to the notification itself --- yeah, you can click the tray icon or whatever, but the notification points to a specific conversation/contact or one message). But what I find ABSOLUTELY UNACCEPTABLE is the way you describe what it should look like, "regardless of theme". Do you think all the people on Earth like black round bubbles? What if they find them annoying, disturbing? It won't be so hard to make it themable, notification-daemon does so, why not? This is not what I am used to in the free software world, forcing your aesthetical feeling upon the users --- it reminds me of one innominate majority OS way to much... --Filip Štědronský (regnarg)

• So I assume that it is pretty pointless to have the option in Software Sources > Updates to check less than 7 days if it's not going to tell you anyway unless they happen to be security updates. On the whole I like the new notifications and them not getting in the way, but I'm not sure that the notification system should be controlling how often it tells me what I want to know. If I want updates to check every 7 days I would tell it so. forestpixie

I hope that Rhythmbox will use OSD to display the next track (with cover, title, duration, ...) in a notification bubble (like amarok with OSD) UPDATE: here a horrible mokup. Moreover when I type "play", "next", "previous" on my keyboard this won't be displayed with a notification (it's only a bug from my computer?). Sorry for bad english (r3dkn16h7).

I have switched from network manager to WICD to avoid having to type my login every time I want to connect to my wifi network. It would be nice to see WICD information coming through notify OSD the same way as it does for network manager [Samuel Rein]

I've modified source code for GShutdown to play nicely with new notification daemon. I've submitted a patch to GShutdown Team but they have to review it and this can take some time... However I've set up a branch at my launchpad account so I (and you) can track changes. screenshot feedback from users with old/new notification daemon is needed. thanks -fm

Matthew, I appreciate your dedication to Ubuntu, but the "abolish the icon and bubble, and instead open the updates window directly" behavior you've championed as part of this just feels very disrespectful to me. One of the things that prompted me to install Ubuntu and move away from Microsoft products is what I view as MS's cavalier, heavy-handed updating behavior. They don't seem to realize that IT'S MY COMPUTER, not theirs, and this behavioral change seems to me to reflect confusion on that issue, as well. I do not want any "phone home" process to unilaterally open windows on MY COMPUTER or to try to browbeat me into taking any action that some other person has decided I should take to modify MY COMPUTER. Yes, security updates are important to me, so much so that I've allowed a particular area of my screen's real-estate to be reserved for notification of their availability. But as important as they are, security updates are *considerably* less important to me than my sense of personal control over MY COMPUTER. You'll say that delaying security updates can be hazardous to that control also, but it damages user's trust to try to force-feed updates in any way, as this change of behavior does. Any concerns (such as launchpad "bug" 175166) that the message "Click on the notification icon to show the available updates" might be misunderstood could have been addressed much more simply, in my opinion, and much less intrusively. The bottom line on this for me is that I've decided to upgrade from Hardy to Intrepid rather than to Jaunty, as I'd originally planned, because I find this change of behavior so distasteful. - ami_nakata

• I’m sorry you find it so distasteful, but for windows to never open automatically would be impractical. The rest of your comment seems a bit confused. Update-notifier “phones home” every day by default, and always has, regardless of whether it opens the updates window or not; that’s a completely unrelated issue. And Ubuntu’s updates presentation is now much less like Windows than it was before, so suggesting that we’re following Microsoft is quite inaccurate. Thanks for your feedback. —mpt

Hi! I have now been looking trough this and onw thing worries me. Where it before was a notification, there is now often instead a dialog popping up focused or unfocused. This is IMO not good. For example, the notification about not removing mounted devices yet seems to get replaced by a dialog. This is not good design. When you need to notify the user not to remove the device, use the new NotifyOSD and don't pop up dialogs all over the place! Thanks! - olskar

• The window warning you not to remove/eject devices that still need writing to is a progress window, not a dialog. We use a progress window because it’s in response to something you’ve specifically asked for (unmounting the device), and a notification bubble might inappropriately disappear before the process had finished. You’re correct on the general point, though, that there are a few programs that still need fixing to use notification bubbles instead of fallback alert boxes. —mpt

Thanks for answering so fast, your answer make sense. However I, and some other people, have another question. When changing song with my keyboard I get one notification telling me what song is playing, so far so good, but I also get a big symbol telling me I have pressed the next track button on my keyboard, we think it just seems a bit unnecessary? I already know I've gone forward or back - I did it just before the system tells me I did.

Check thread in the forums here: http://ubuntuforums.org/showthread.php?t=1116161

• That was a CEO decision. The keyboard confirmation bubbles were pulled out from Jaunty at the last minute, but they’ll return in Karmic. —mpt

I also have a question about hovering over the notifications, I've read somewhere that when hovering over the notifications (making them transparent), the timer that closes them will be paused. Is that true? That would be desireable! -olskar

In regard to Update Manager, could we please have an option to return to the old behavior? I understand the rationale for the new one, but I strongly dislike the idea both of windows opening without my consent (as a regular function!) and of not knowing for a week about non-security updates. (Obviously I can change the setting for the latter, but then I have even more windows popping up!) I like the idea of the new notification system but I hope it will, on the whole, be used to corral all the wayward notification systems present in Ubuntu and make notifications as rare and unobtrusive as possible.

I think Ami’s point before was that a notification icon seems pleasant, new updates being delivered to you as they’re available, while an unwanted window seems somehow rude and obtrusive. I’m a writer, and the idea of being presented with windows full of words—even without focus—at the beginning of the day (or worse, in the middle of the day!) kind of chills me to my core. I would really, strongly appreciate an option to return to the notification icon for the Update Manager.

Thank you! —TinaRussell

Users who wish to continue receiving update notifications in the previous manner can restore the earlier behavior using the following command: gconftool -s --type bool /apps/update-notifier/auto_launch false That will be mentioned in the releasenotes -olskar (Thanks! —TinaRussell)

I'm perfectly happy fiddling with gconf, but on behalf of the many users who will never have heard of gconf before, I'd like to register extreme discontent that this didn't get given a proper UI setting. -maxb.

The issue with lowresicons in pidgins buddyicons ( https://bugs.launchpad.net/bugs/338695 ) (check here for image: http://pici.se/396034/ ) is unfixable. That image is the only image we get from MSN and there is no way to make it bigger without upscaling it (and making it look bad). The only way this can be fixed is to use a smaller picture inside the bubbles, comments on that? -olskar

• Thanks, I’ve now reported that as a separate bug. —mpt

I really like reading instant messages from Pidgin in the notification bubbles, but occasionally I will receive a really long IM which I can't fully read before the bubble disappears. Perhaps the bubble should remain on the screen an amount of time proportional to the amount of text in the bubble? It would be nice if it could be adjusted for different reading speeds. --Omegamormegil

I'm sure I'm in the minority, but one of the things I hate about MS Windows is that it frequently distracts me from what I'm doing with stupid pop-up bubbles for the most irrelevant of things -- like connecting to a wireless network. There is a little icon in my notification area that tells me stuff like that. I don't want stuff appearing and disappearing from my work area, especially not with fading or sliding effects. In previous versions of Ubuntu, I was able to chmod -x notification-daemon to get rid of this, but it looks like you're adding more and more functionality to pop-ups and planning on getting rid of the notification area altogether. Also, pop-under windows are particularly annoying. The notification area is the only place where I have given the OS permission to "notify" me of anything. Put an icon there if I need to know something, and if I wonder what it is, I'll mouse over it, or click on it, or whatever. There is NOTHING so important that it needs to interrupt what I'm doing by littering my workspace. I understand other people's need for eye-candy (and ritalin), but please, let us old timers shut off the cute stuff, and limit it to the notification area. I also just noticed that when I use my keyboard volume buttons, the volume control uses the new pop-up framework, which instead of being theme colored and in the middle of my screen (obviously if I'm pressing buttons, this isn't an unwanted notification), it appears in a black window in the upper right corner of my screen where it doesn't belong, and where it blends in with my black background. I know you guys are all about a "single experience" and making all the apps look the same, but make sure you don't make all the apps suck with no way to get the old behaviour back! --Brian

The proposed update to gnome-screensaver opts to use a pop-up instead of a notification to notify the user of a left message. I believe a better system could be implemented, since I consider a pop-up obtrusive. http://brainstorm.ubuntu.com/idea/19482/ -- Kareeser

I agree with you Kareeser. Pop-ups should be avoided wherever they can, I think everyone can agree with that, and I think your solution with integrating it into the notification-applet is elegant. -olskar

Would it be possible to get a notification when pressing Caps Lock / Num Lock? There's also something I find annoying about the bubbles is that they fade out, then flicker on again and only then hide. --astron

I don't want to trivialize your work, but not everyone likes or wants eye candy. I want performance...the more eye candy, the more CPU cycles taken from something useful. I guess the best option is leave the user the option to have it or not. chmod -x notification-daemon didn't work, but I found a way. For those who love it, great! For those of us who are drastically annoyed by popups, give us a mechanism (reasonable) to turn it off! --Doc

Could Firefox (or Empathy or Transmission or Nautilus copy between mounts(?) or foo) use notifications for transfer complete, with a transfer indicator keeping track of current downloads and unacknowledged completed downloads? 'All downloads complete' wouldn't be necessary. Elegance in how progress within the indicator is displayed would be desirable though. -- JimPutt

Suggestion: It's good that notification logs was accepted and implemented in time for Jaunty. For Karmic, I expect a GUI for the log, ideally IMHO from Indicator applet, alternatively from Sys/Adm/Log Viewer. -- FelipeFigueiredo

Regarding ontv: "When a new program matching your criteria is detected, a notification bubble appears that, when clicked, opens a dialog with more details of the program. Instead … "

Instead I think only a notification should be shown with the name of the program and time it starts, there is really no need for a button that when clicked opens details. -olskar

I think notify-osd should be added to Debian, so applications can start the testing there and be synced more easily in the future. (Some Ubuntu members are Debian Developers, and they can help to maintain it there). -Marco Rodrigues

I think making these non-interactive was a mistake, though I do understand the reasoning. For example, trivial notifications might not deserve a full 5s (or whatever) and the user choice in dismissing them is basic usability. Displaying something that the user can't interact with is just plain wrong, even if you think they don't need to interact with it. Of course, whether they do or don't is an empirical question: For example, I just had a notification that refused to disappear over the course of several minutes, which is beyond distracting. I killed the process and uninstalled notify-osd because that is a bug, not a feature (even if it had disappeared on it's own, it's still a bug). That said, these notifications look much nicer than the previous system, and the effort isn't wasted, even if some missteps are made along the way. -Mike.lifeguard

I've added support to GNOME Terminal to show a notification when the terminal beeps. blog with screenshot bug with patches --MikelWard

Regarding Rhythmbox, I use "Music Applet" in conjunction with it, which does use notifications. (This is an applet that places basic play/pause, previous, next buttons in the task bar.) Under Jaunty, the notification bubble would change each time the forward or reverse buttons were clicked--handy for jumping through tracks quickly without having the full Rhythmbox window visible. In Karmic, however, the new "spam prevention" feature seems to hinder this functionality. The bubbles do change, but each one displays for its entire life cycle of several seconds before the next one appears. So, I can click "forward" many times before even the second notification displays. Obviously, this behavior renders the notifications functionally useless in this application. Is there a way to modify or configure this behavior? -Darren Gibson

I have removed notify-OSD from my system - First, the location is too annoying and I cannot set it (or the group - statck them from the bottom or top left if you must). I should be able to select any corner. Second, it stays up too long - also cannot be set by anything I can find - and cannot be dismissed. It often covers something I need to see, but moving the mouse over causes an epilepsy inducing flash. Too many applications have trivial notifications which cannot be shut off - e.g. edit a file in ~/Ubuntu One, and you get a series of "UO is updating", "UO has finished updating" flashes. I can't fix hundreds of noisy apps. Maybe it should ignore the first click, but it should have a DISMISS and GO (like for IM to particular conversations, playing, etc.) instead of being a ghost box. I also might not mind it if it has settable transparency, but it doesn't have that either. This is supposed to notify me, not annoy me. So are you going to replace vi with vigor because it has better notification? Note I have a small screen so a tiny box is very annoying because it takes up a lot of screen - it probably wouldn't bother me as much on my HD monitor, but I'm usually using the netbook.

Shoving a "one size fits all" notification system down the user's throat is a bad idea. Why not just block the entire screen and all mouse and keyboarding for 5 seconds - the user would definitely notice.

In summary, for this not to be annoyware:

1. Settable corner to be used. Reverse the positioning for priority from the bottom

2. Settable popup duration.

3. Settable transparency so I can see through the box instead of the opaque screenblock flashy on mouseover behavior.

4. a dismiss mechanism (I'd rather have them up longer but dismissable).

5. a respond button to signal the application like the old mechanism.

-tz

I absolutely concur, I've gone back to GNOME's notification-daemon, which IMO provides a far superior user experience. -- maxb

The length of time that the notification last for and the inability to dismiss them are both very annoying. I'm going to revert to the notification demon as well. I would also like the ability to ignore certain notifications (eg network manager up/down messages, I can look at the icon for that)

LukeRazor

• The notification just suddenly and surprisingly appears resulting in unnecessary distraction from what one is working on, an effect such as a slide-in or fade-in would create a more pleasant workspace. -- lordmetroid 2009-08-27 21:25:28

• People among others including me is kind of irritated on the location of the notification messages and bug report was filed but declared invalid. A means of configuring the behaviour and location would be welcome. -- lordmetroid 2009-08-27 21:25:28

• I think that volume changes should be NON-CRITICAL in notify-osd, so that they are NOT displayed during fullscreen video playback or fullscreen applications. Please vote for my brainstorm idea here: http://brainstorm.ubuntu.com/idea/21495/ --humphreybc

• Definitely needs to be a way to set preferences - on the eeepc NotifyOSD takes up far too much space. Also, sometimes I just don't want to know - eg while I'm in MPlayer full screen, I don't want to have a pop up everytime I pass an open wireless network on the train. --datakid

• Many people search for way to turn NotifyOSD off and go back to notification-daemon. This is a valid concern until NotifyOSD fixes their issues so here is the easy way:

$ sudo mv /usr/share/dbus-1/services/org.freedesktop.Notifications.service /usr/share/dbus-1/services/org.freedesktop.Notifications.service.disabled
$ sudo mv /usr/share/dbus-1/services/org.freedesktop.Notifications.service.notify-osd /usr/share/dbus-1/services/org.freedesktop.Notifications.service

PrebenR

The notify-osd is really annoying due to the long and unsettable timeout. I'm using notify-send to tell whether the touchpad is enabled or disabled after I press a hotkey. Why do I have to read: Touchpad enabled for 10 seconds? If I press the button two times I have to wait 10 seconds to get the notification that I disabled it again and then another 10 seconds before this notification goes away. This notification only needs 1 second before timeout. If some users need more time it should be user configurable.

With Karmic notify-osd is as annoying as the new gdm...

I really hope the developers reconsider their stance on the timeout issue!

AlainODea

The Interaction section requires that the bubbles provide no interaction and fade when the mouse is over them.

The inability to click on the notification bubbles makes them inconsistent with notification bubbles on all other platforms. This makes them much less useful to me for Empathy where I would expect to be able to click them to raise the updated chat. This one size fits all notifications for all kinds of events is no solution at all. I have wasted significant time searching for a replacement for this broken functionality. Please drop this ill-reasoned requirement of the spec.

(Note: the "you" in this post is an abstract "you", not to be taken personally)

I've installed Karmic for two friends in the last 6 weeks, and their reaction to this has been the same as my own was: the bubble pops up, they mouse to it, and it vanishes. So they mouse away, back to what they were doing before, and it pops up again. For new users especially, this is as counter-intuitive as it's possible to be: as dozens of others have pointed out.

The Theme is The Theme. Saying "I don't care what the user wants, MY way is best" defeats the purpose of themes in the first place. Even if your way IS best in the abstract, which it blatantly isn't **, it's still the user's choice to make. It's their desktop, not yours. Given the overwhelming opposition to the current behavior, which only its creators seem to be in favor of to any degree, it seems fairly clear what the vast majority prefer, whether they're "wrong" or not.

** If my desktop is predominantly dark, your forcing of the bubble to "also black" makes it LESS visible, not more. The whole point of HAVING "system colors" rather than everyone picking their personal favorites and hard-coding them into their apps is that you get contrast where you want it, you don't get it where you don't, and everything behaves consistently.

Since you insist on hard-coding the background, the foreground has to be hard-coded as well. Great. So now you've lost the ability to color-code by severity, except that some (TINY) fraction of the total space will be red if something's really hit the fan.

Perhaps the visual design is "good" and "suitable" if you're using maximum effects and a Gnome3 beta desktop. In which case it should have been deferred until that was actually ready, and/or had its appearance determined BY the user's Beryl/Compiz settings. Or, yknow, that whole "Theme" thing that you're so set against. It certainly isn't good or suitable if you're running on a laptop; or in a windowed VM.

The bubble is ludicrously large for virtually everything it claims to be intended for. If the jack icon with a giant red X through it is somehow not clear to me, I can click on it to be told what it means - and then ideally have it do something Actually Useful, like open the Connections panel, *gasp*.

This isn't so much a "generic notification widget" as it is a one-way chat client. It looks like it does that quite nicely, but that decision/desire also makes it predominantly unsuitable for the role it's pretending to fill, in its current state. If you wanted something that would let you see pidgin/empathy/etc without having to refocus, that's perfectly reasonable and a desirable goal: but it should have simply been written AS that.

You're trying to make it a Kitchen Sink, and it's struggling in exactly the ways anyone would expect. the "minimum" size has essentially been chosen by "what will a tweet fit into?", along with the minimum and maximum durations, regardless of how appropriate they are for anything else - and rather than fix the design, the solution is to say "who cares? anything that needs real notification should ignore NotifyOSD completely and use its own modals".

One size does not fit all, nor does one time, and nor does welding it to the top right of the screen just because that's where you personally have dead space. This is especially comical with network-manager, where simply mousing TO the panel element removes the very alert that prompted the mousing and then brings it back up when you REACH the NM icon to actually start addressing the problem. On a laptop, where people are using a touchpad, it's extremely common for them to be out of movement space just before the edge of the screen, at which point the OSD vanishes, while they move their finger back to the center of the pad to get the space/control they need to be able to click the icon - which you've now incorrectly told them they no longer need to do...

Despite all that, there is actually a good CONCEPT here: it just can't get over a handful of critical weaknesses in the design and implementation. The design even has many good points, but they're just massively outweighed by the bad ones - "the surgery was successful, but the patient died".

With the Lynx UIFreeze imminent, this obviously isn't going to get properly fixed for that, but it could certainly be triaged in time.

• Duration

Fixed durations are a terrible idea, and one of several reasons why the current behavior will (and does) consistently fail to make ANYONE happy. They're annoyingly long for some users, and far too short for others. If my dad has something this stupidly-huge pop up, he's going to look at it and wonder: "what's an ethernet, and how do I fix it?". And then he's going to get a pen and a piece of paper so he can write down what it says, at which point it'll be gone, he'll have no internet, and he'll have no idea what he's supposed to do about it.

• CRITICAL EVENTS MUST BE SUSTAINED UNTIL THEY ARE EITHER ACKNOWLEDGED OR RESOLVED

This isn't rocket science, and you clearly understand that this is exactly the behavior that it SHOULD have: because that's why everything that's actually important has been told NOT to use NotifyOSD.

Put a bar in a panel. Color it by the highest-severity ACTIVE event, with short, meaningful text for the color-blind. Like, "ALERT".

• If the power goes out while I'm getting a drink, I need to be able to see that when I get back. If the power goes out while I'm stretching my legs in the garden for ten minutes, but comes back before I get back to my desk, I don't care, and I don't need a Red Alert on my bar.

  Hacking the power daemon and every other "key" app is a lot of duped code and effort that could all be avoided just by fixing NOSD's design, and oh look, now we have a consistent programmatic interface and a consistent user interface.

• History

Maybe my Empathy is buried under a dozen other windows or pinned to a different desktop, and someone IM's me while I'm getting another drink. Of course, the way things are ATM, I'm never going to see that message: not until I close down whatever it is I'm working on, and find out the message is already expired in real life - say, some friends are going out for drinks, but only for an hour. I'm fairly sure I'd prefer to have a nice green stripe indicator somewhere than to have missed them. I can instantly see that something happened while I was AFK - but I can also see that it wasn't important.

hrm...

tail /var/log/syslog and hope it's not flooded by all the other sysmsgs? Check every app and applet at random until I find which one of them it was, if any? or click my bar and instantly see exactly what happened? Tough call. You'd need, what, 6 max? NOSD is somehow burning 3.6MB even though it does / is doing absolutely nothing, so I'm pretty sure another 500 bytes or so isn't going to kill it. :P

• Position

Every WM supports remembering a window's position - even though metacity refuses to actually use it and insists on slamming everything onto the left-hand edge of the screen every time. >:(

And since we were smart enough to implement the persistent panel bar, we have a "root" node that the user can position wherever they want - and even better, can put along the edges of the screen that are never obscured. And interact with to (re)position the popup if they want that top-right piece of real-estate back, or configure durations etc without having to take random stabs in gconf-editor's haystack and/or google for.

• Color and Alpha

Yes, suboptimal decisions have been made. No, it's not crucial to fix them. One more piece of random mismatched desktop ugliness isn't going to make a big difference. :P

--

> The Play/Pause/Next/Previous confirmation bubbles are not included in Ubuntu 9.04, because they resulted in either two notifications of an event, or one notification of nothing happening (bug 343261, bug 345363, bug 351986). Should the idea be retired permanently?

Blatantly so. Those are (a) user-initiated actions that (b) have immediate feedback through both audio and tactile. Do we really need triple confirmation that we did indeed press a button?! If the motivation for this is the poor latency of pulse/alsa/xmms/etc, those are Not Your Problem.

goobox> When a music track starts playing, a notification bubble appears containing “Next” and “Stop” buttons. The button[s] should ...

... not even be created in the first place, ffs, nor should the bubble around them. Again: I CHOSE to play it, I can HEAR it playing, why on earth would I need, let alone want, an annoying, opaque, huge, unrelocatable SPLAT on my desktop to go with them?

> When there is a kernel oops, a notification bubble appears asking if you want to send the error to the Kernel Oops Web site, containing five buttons: “Always”, “Yes”, “No”, or “Never”, and “Details”. Instead, this should be an alert box with four buttons, and an expandable section to show the error log

What is this obsession with hiding "Details" from users all the time in GNOME anyway? (And not remembering what the user set it to last time in anything?) By the time this happens twice, Average User is going to opt for either "Always" or "Never". The only people who are ever going to make this decision on a case-by-case basis are Helpfuls, Obsessives, and Developers - who need to SEE those details to make an informed decision.

eesh - that turned out to be FAR longer than I'd planned...

Anyway, some food for thought. gl.

-- arQon 2010-02-13 00:02:28

Looking at the "Unresolved Issues" list:

> Put notifications in a text log.

No. (debugging purposes aside)

• NOSD by definition does not "own" the notification. It's implicitly the responsibility of whoever DOES own it to either send it to the right place (syslog, IM, etc) or choose not to log it (email etc). Multiple copies of trivial events (eg IM) is a resource waste, but that's not the point. Your grandmother isn't going to know that if she didn't quite finish reading an event in time she needs to fire up a terminal and run something called tail with a bunch of gobbledygook after it to see the message, and she shouldn't have to. That's just ridiculous. Note that this is essentially solved by the triage redesign suggested above.

> Because we have a queue, bringing a chat window to the front should remove from the queue all notifications from that person.

Responsibility for that clearly lies with the app that submitted the events in the first place, both conceptually and technically.

> “frustphil”: What if you use the keyboard to focus a control that is underneath a currently-open bubble? For example, Ctrl K to focus Firefox’s search field.

The only correct behavior for this is implicitly to drop the bubble. The cursor is the cursor - how it got there is irrelevant, and you do not have the right to block Express User Intent/Activity.

• Again, the issue is a direct consequence of the current design (where either the user is DoS'd for x seconds; or the event is lost forever since a typing user will not be able to mousemove the cursor away from NOSD - and given its static placement, the same can and will happen in vi, and OpenCALC, and even in apps that ARE mouse-driven if the user is doing something like CAD/GIMP/etc and not in a position to immediately drop whatever they're doing just to have to deal with a random interruption). And again, this is resolved by the triage suggestions.

> Should there be a manual way of entering "do-not-disturb" mode?

Obviously.

> e.g. by setting IM status (though going online to get fewer notifications could be a bit counter-productive).

Ah, there's the admission of it being primarily a chat client. (I expect I read that before my last post and it subconsciously influed that realisation).

• Again, design flaw leads to desperate but still unsuccessful attempts at workarounds. If I don't run IM at work, what possible justification is there for me having to start an IM client just to disable notifications before a presentation? If the office has a ban on IM apps, do we just all sit there and put up with the banner spam every time an email comes in? Which IM client did you have in mind? Empathy? Gajim? What if I prefer one that hasn't been updated yet, or where the author refuses to hack in this completely unwarranted feature that impacts his codebase for no reason? Again, this is resolved by the triage suggestions.

> djsiegel: Should bubbles be wider by default? That would make longer messages easier to read, but could make confirmation bubbles look a wee bit weird.

Possibly - but they're already far too wide for anything but chat. Of course, if they followed the same rules as absolutely everything else on the desktop and were resizable, colorable, and had a selectable font, they'd make not just you, but the other half of the userbase who want the default to be SMALLER, happy. (What's the word for a solution that completely satisfies two parties who have directly opposed desires? It's not a concession, because neither side is giving anything up. Mutualism implies co-dependence and requires a common goal, which isn't the case either. Anyone know?)

> The changes made to update-notifier have spawned a series of serious discussions with multiple bug reports which are combined in #332945.

Within a day, that had deteriorated into users acting like brats to devs, and devs telling users to go fork themselves. Six months and 400 posts later, neither side's stance appears to have changed at all.

• I have no interest in the pissing contest: I just want software that Sucks As Little As Possible. You're 0 for 2 so far on this one (though I expect half the aggravation is caused by all the bugs in update-manager incorrectly demanding an su at the wrong time, failing to actually check for updates when started by hand, and so on). Obviously, the triage suggestions resolve virtually all of this particular conflict as well, and do so in a superior way on all fronts te *either* of the previous attempts.

> Windows has an API for the "old" behavior of popping up persistent bubbles (with actions). When Wine attempts to properly implement this API, they'll have to make a decision about how to handle applications expecting the old-style persistent bubbles.

Or, alternatively, you could fix the design using the scheme above, at which point one of the largest, most important, and most complex projects in the linux world wouldn't have to jump through hoops because of a mistake made in a completely different part of the system. (Not that they would really "have to" anyway, since they'd just keep using custom modals the way you suggested everything else that was actually "important" do).

> If the pointer is left resting where notification bubbles would otherwise appear, perhaps future bubbles should appear in a different place until the pointer moves elsewhere. [Cody Somerville]

Fundamentally the same problem as frustphil's, with the same solution.

I make that 6 for 6 "major" resolutions just by applying the first two fixes, with 1 "minor" item left which would require the third one. Do I win an Internets? How about a free copy of Ubuntu? :P

Now we just need a developer who can knock it out in the next 2 weeks...

--

The funny thing is, the core concept did need to change, and I don't think anyone was really opposed to that aspect in and of itself. The notification area IS too small to really be noticed by casual users, and esp so with the default theme; and the icon was absolutely meaningless to the majority even if they saw it.

The problem is, you replaced a poor solution with an even worse one, and then rammed it not merely down everyone's throats in the face of near-unanimous opposition (which I'm fine with - at least you've got some backbone :P), but across huge unrelated swathes of the system as well. If the NOSD design had actually been good, it would have been a crowning moment of vindication when it all came togther. But it wasn't, so instead there's the still the same animosity among the community and mediocrity on the desktop 6 months later.

Interestingly, the *wire* protocol is actually fairly decent. It's a bit sloppy, and it's got a couple of flaws in it, but it's mostly solid. If apps are (correctly) developing to THAT rather the specs laid out here, you've still managed to do a Good Thing Overall in the long run even though it was such a cluster in the short term - kind of like how Vista was abysmal, but it at least got IHV's to start making non- pure-kmode drivers and some users to not run as root 100% of the time, which made the transition to Win7 a lot easier for them both.

If Ubuntu/GNOME/whatever actually GETS to the Ends at some point, they *will* justify the Means. After all, if a story has a happy ending, everyone forgets about the misery in the previous acts, and software is no different.

gl

-- arQon

Adding my two cents, though most is just repeating the already stated...

Colors and position MUST be configurable, and preferably automatically use suitable values for the system. The black boxes on top-right may work well with the default dark theme of Xubuntu (don't know about default Ubuntu) but dark themes strain my eyes and I much prefer a light theme. In this case the OSD colors look god-awful. I also hate using a lot of space for panels, so I have only a single very small panel in the lower-right corner. The OSD jumps up completely unattached in a very strange place.

I can't see any reason why the OSD couldn't take it's colors from the current theme. That's precisely why themes exist! Even better, themes could in the future optionally include separate definitions on what the OSD should look like. Similarly the position should follow the panel's notification area by default.

The disappearance and reappearance when hovering is also extremely irritating and counter-intuitive, as has been said earlier. It leaves a feeling of "Ha-ha, you can't close me!" and the frustration that you are not in control.

The worst thing is that the earlier system was fantastically beatuful (I'm not sure is this separate or whether it still exists). A clean bubble that displays directly on the notification icon, and allows action to be taken when necessary. See the bluez-gnome example for instance.

I just found a patched version of NotifyOSD and a GUI for configuring it (http://maketecheasier.com/easily-customize-notifyosd-ubuntu-lucid/2010/05/26). Now the OSD looks much better, though still far from perfect. The text has a hard-coded black blur around it making a black text on light-gray background impossible, and the position cannot be moved to the lower-right, but it's still a vast improvement. I hope these will be incorporated in future versions.

Thanks for all the work, this is one area that desperately needs it in Linux desktops. I just hope the end result will respect user's desires for customizability instead of forcing everyone into one mold. (That's exactly why I no longer use Gnome, and prefer XFCE instead.)

-- Sampo N.

Do Not Disturb Mode

So.. how's the development on IPC with the FUSA coming? As i read elsewhere (https://bugs.launchpad.net/notify-osd/+bug/428509), this was on ToDo-lists for more previous release cycles already.. I think if we are brave enough to introduce a whole new notification system with all the doubts and questions attached, we need to address the basic functionality issues of it at least, one of them being actually NOTIFYING. Currently, NotifyOSD does NOT notify if an application is in fullscreen mode, unless the notification is marked critical. This is not how to do things IMO

Nnaji

Fade/Dismiss/Stacking

I was just playing around with notify-send, and had a few observations about the NotifyOSD, as evidently so have many vocal others;

• Users should get to choose which corner (of which screen!?) the notifications appear
• The fade time is excruciatingly long, this should be adjustable.
• regardless of adjustable fade time, there should be a dismiss button. blurring is fine for a mouseover, but if I click on it, I want it gone!
• finally, Stacking. Look to Growl for how to do it right. Fade/Dismiss is less infuriating to go without when you don't have to watch the messages pass by one by one.

seriously. Any of you that disagree with the multiple fade/dismiss/stacking comments should run the following one-liner, then re-assess your position:

  for ICON in /usr/share/pixmaps/*xpm; do notify-send `basename $ICON xpm` "this icon is:\n\t$ICON" -c ICONTEST -t 500 -i $ICON;sleep 1; done

-- Gavitron

Reconsider the addition of actions!!

There are certain moments when actions are just perfect: the message is not critical, it could fade away without much ado and having some interaction does not kill anybody.

* Firefox: download complete! Making Firefox open the download window without focus is very obtrusive. And maybe the user really doesn't want to do anything with it. So, a small bubble appears with an action or link and nothing is really wrong if the user miss it: "OK, let me keep browsing I'll see that later". * Chat: Someone is on-line, the bubble appears and the user just wants to say hello. A small button lets the user say "Hello". Instead, the user has to go down there and search on the contact list to find and finally chat. * Mail: The mail is there and it's not going to disappear. Having a button there is just perfect... no, I don't like the messaging menu that much. * Twitter: Most of the messages on Twitter are of no urgency. But sometimes, when something appears the user wants to reply. Again, the interaction is broken. * At least, clicking on the bubble should give us something back!

Playing hide and seek with the user is not natural. I really had to go to the Wiki to find that this behavior is intentional. And there is no way to customize it. I really understand the importance of this change: bubbles where heavily misused. Just because they are beautiful developers use them to show critical messages that are misplaced and disturb the rest of the ecosystem, but actions aren't really that bad.

-- Tristán Grimaux

Counterintuitive Interaction

I'd like to add another vote to change the "Interaction" section. When notifications pop-up, I sometimes can't read the entire message before it fades away. My first instinct to prevent this is to hover the mouse cursor over the notification, to prevent it from disappearing. This has the desired effect on notifications on other platforms I have used (whatever "fade out timer" the notification has is paused until I move the mouse off the message).

I am curious as to the rationale behind the current requirement. Are there user requests or user testing data that indicate this is how people want or expect a notification to behave? In my personal experience, if I want to see the small section of screen covered by a notification, I will either click on the popup to make it disappear, or wait until it fades on its own. This is assuming a default action for popups is dismiss -- I agree with other comments suggesting that clicking should have a configurable action (e.g., open the full message / tweet / email so I can reply, etc.).

-- Larry Archer

Device Notifications

I have developed pyudev-based device notifications. Currently they show more detailed information for some devices, but the app can be easily modified.

For example, when USB WiFi adaptor is plugged, there are two notifications "Device Added, USB Device, some-device-model", and then "Device Added, WiFi Device, more-detailed-device-model-description", which actually is better than the dumb uninformative notifications originally suggested. I mean, when I plug-in device I KNOW that I plugged a new device - there is no need for notification saying only "You plugged new device" - this is obvious.

I think the user may be more interested to see as what device (vendor, model) his device is detected. udev-notify page in LP: http://launchpad.net/udev-notify

-- Krasimir Stefanov