Revision 43 as of 2009-04-07 16:42:12

Clear message

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

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

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 - 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 <>

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

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

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.

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?


--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