+ replies to BUGabundo, JorgeCob, ScottKitterman, MichielBeijen
|Deletions are marked like this.||Additions are marked like this.|
|Line 15:||Line 15:|
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
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
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
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
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
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. 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?
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)