Comments

Differences between revisions 52 and 53
Revision 52 as of 2009-04-20 14:58:21
Size: 21723
Editor: dsl-tn-dynamic-250
Comment:
Revision 53 as of 2009-04-21 08:38:25
Size: 22309
Editor: ABTS-TN-dynamic-220
Comment:
Deletions are marked like this. Additions are marked like this.
Line 136: Line 136:
 3. body ""text size"" of the notifications (not the title text) should be atleast the same size of the applications fonts to be clearly visible, since in the present config the size of the text is smaller than the applications font size, which makes the notifications difficult to view... --mac_v  3. body ""text size"" of the notifications (not the title text) should be atleast the same size of the applications fonts to be clearly visible, since in the present config the size of the text is smaller than the applications font size, which makes the notifications difficult to view...
 4. changing the behaviour of ""firefox"", to auto open the downloads window and request attention, is again making it feel like pop-up ads. since the default download location setting is to download to desktop , so why does a window need to be opened? the existing behaviour of firefox is nice... hope this could be duplicated using the notify-osd and action buttons, else its better left alone... ""Notify-osd shouldnt modify the application's behaviour, rather find a pleasant and uniform way to integrate the notification into the system as its intended notification purpose""...
--mac_v

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

first i'd like to say,the notify osd concept is a wonderful one and it looks good, but i have these problems with the present functions:

  1. ""color of the notifications"" are full black which makes the popups difficult to notice when the user has a dark theme and a dark background...>>>an easier solution would be to give a ""1 or 2 pixel white border which would highlight the notification"" from a dark background , i guess this would be easier than giving color options for the background&foreground colors

  2. the present ""update notification"" or lack of immediate notification is a cause of concern,this problem is two fold
    1. the present update setup is not user configurable as proposed in the original update manager mockup , "not providing the option when the user should be notified" is a bad implementation rather u have the default to display updates only once a week. when this part of it was not complete why did the devs push this out?

      b. pop-under window is the "most obtrusive" implementation , makes it look like pop-up ads....>>> a solution for this is rather than a pop-under window,display the updates in the notification bubbles[original idea from xpd259 ] ""present the updates as a larger notify-osd display"" and as you already have the idea to allow action buttons in the notify-osd , it would be nice if there was only just have a single button for the user to choose <update now> ,and making the notify-osd stay longer for these update notification...so they end up being less intrusive than the pop-under windows and atleast have an option for the repeat reminder , x mins , which users can choose from in the updates notification settings tab... i think this would be the least obtrusive update notification, that the devs hope to achieve

  3. body ""text size"" of the notifications (not the title text) should be atleast the same size of the applications fonts to be clearly visible, since in the present config the size of the text is smaller than the applications font size, which makes the notifications difficult to view...
  4. changing the behaviour of ""firefox"", to auto open the downloads window and request attention, is again making it feel like pop-up ads. since the default download location setting is to download to desktop , so why does a window need to be opened? the existing behaviour of firefox is nice... hope this could be duplicated using the notify-osd and action buttons, else its better left alone... ""Notify-osd shouldnt modify the application's behaviour, rather find a pleasant and uniform way to integrate the notification into the system as its intended notification purpose""... --mac_v

NotifyOSD/Comments (last edited 2012-08-08 22:03:18 by 99-129-134-24)