Re: [Ayatana] Merging libindicate into libnotify
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Conscious User wrote on 01/04/11 18:57: The idea that all non-immediate notifications should be grouped together in a single place, regardless of topic, is very much like the idea that progress for all long-running tasks should be grouped together in a single place regardless of task. It's the kind of categorization that may make perfect sense to engineers, but to others it risks looking like a jumble of unrelated things. What are your thoughts on, for example, what Jockey, PolicyKit and File Transfer currently do? They basically use an appindicator to persist, just like Update Manager did in the past with the notification area. Do you think this should be the standard procedure for all apps that do not fit in the current categories (messaging and sound)? Absolutely not. If no, how should they be fixed? If yes, why not do something similar for Update Manager instead of popping up the window? Designing a replacement for Jockey's menu is something I'm working on this week. Maybe it can be merged into Update Manager, or maybe there's a better place for it. Anyone got suggestions? http://launchpad.net/bugs/617392 Even if these one-off menus were a good idea, the PolicyKit one -- like the Jockey one -- would be more confusing than useful: I doubt there is any rewording of Drop elevated privileges that would be widely understandable. I think this should just be deleted, or replaced with a Remember my password for 5 minutes checkbox in the Authenticate dialog. http://launchpad.net/bugs/550502 And the File Operations menu is just a workaround for not having a real progress window, i.e. a window that is minimizable but not closable. http://launchpad.net/bugs/534477 One of the motivations behind the introduction of Notify OSD was to encourage applications to use general-purpose notification systems less often. Notifications of things are more helpful if they are closer to those things, for example embedded in relevant windows. Aren't the most common usage of notifications the situations where relevant windows are *not* currently in sight, or when there is no such thing as relevant windows at all? Only if you define notifications as things that aren't already being shown in a relevant window. :-) - -- mpt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2a3jsACgkQ6PUxNfU6ecoAEACfZSy/BMk+xNYT224xqrAe07aT D9wAn37h5BJY44T8CmZ5OJd7IBZDOOnA =l5C3 -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Merging libindicate into libnotify
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Conscious User wrote on 31/03/11 18:57: ... In Natty, the Ubuntu One item was moved from the Me Menu from the Messaging Menu. Was this agreed on by the design team? Not as far as I know. I reported a bug about it that was marked Invalid. http://launchpad.net/bugs/740340 After that, I discussed it with the Ubuntu One tech lead. I suggested that Ubuntu One use its own indicator menu, which glows when there are share invitations, and otherwise just animates slowly when syncing. As long as it's in the messaging menu it can't show sync progress, without being present in the launcher too -- which both consumes a lot of space in the launcher for something that really isn't that important, and means Ubuntu One status is being shown in two (or one-and-a-half) different places on the screen. If it was, I think this is a good opportunity to wonder if there is still a point in trying to tie the Messaging Menu to messaging applications only. Currently, the messaging menu is the desktop resource that covers that case where notifications require response but not necessarily immediate. The no-response case is covered by the bubbles and the immediate response case is covered by unfocused dialog boxes, or whatever will replace them (the never implemented morphing boxes in the specification or the IDO thingies that Empathy is using now) in the future. The existence of libindicate is something that has always bothered me. The not-necessarily-immediate-response case is a common scenario required by a significative number of applications, and requiring those applications to support an extra library (and thus extra patching for working in Ubuntu) is unpleasant. Shouldn't this case be covered by the Notification Spec and each desktop offer a standard single mechanism for handling them, independently of the app? Shouldn't the Messaging Menu drop the messaging app requirement and become the standard Ubuntu mechanism for handling these kind of notifications? ... The idea that all non-immediate notifications should be grouped together in a single place, regardless of topic, is very much like the idea that progress for all long-running tasks should be grouped together in a single place regardless of task. It's the kind of categorization that may make perfect sense to engineers, but to others it risks looking like a jumble of unrelated things. One of the motivations behind the introduction of Notify OSD was to encourage applications to use general-purpose notification systems less often. Notifications of things are more helpful if they are closer to those things, for example embedded in relevant windows. - -- mpt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2VraUACgkQ6PUxNfU6ecrp8QCgoJqwqOb9qScXDwhY/2yohe8e p4kAoLYaZTVGgtk6JT83LnCtIReP0I7g =j9Ap -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Merging libindicate into libnotify
The idea that all non-immediate notifications should be grouped together in a single place, regardless of topic, is very much like the idea that progress for all long-running tasks should be grouped together in a single place regardless of task. It's the kind of categorization that may make perfect sense to engineers, but to others it risks looking like a jumble of unrelated things. What are your thoughts on, for example, what Jockey, PolicyKit and File Transfer currently do? They basically use an appindicator to persist, just like Update Manager did in the past with the notification area. Do you think this should be the standard procedure for all apps that do not fit in the current categories (messaging and sound)? If no, how should they be fixed? If yes, why not do something similar for Update Manager instead of popping up the window? One of the motivations behind the introduction of Notify OSD was to encourage applications to use general-purpose notification systems less often. Notifications of things are more helpful if they are closer to those things, for example embedded in relevant windows. Aren't the most common usage of notifications the situations where relevant windows are *not* currently in sight, or when there is no such thing as relevant windows at all? ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
[Ayatana] Merging libindicate into libnotify
Hi, In Natty, the Ubuntu One item was moved from the Me Menu from the Messaging Menu. Was this agreed on by the design team? If it was, I think this is a good opportunity to wonder if there is still a point in trying to tie the Messaging Menu to messaging applications only. Currently, the messaging menu is the desktop resource that covers that case where notifications require response but not necessarily immediate. The no-response case is covered by the bubbles and the immediate response case is covered by unfocused dialog boxes, or whatever will replace them (the never implemented morphing boxes in the specification or the IDO thingies that Empathy is using now) in the future. The existence of libindicate is something that has always bothered me. The not-necessarily-immediate-response case is a common scenario required by a significative number of applications, and requiring those applications to support an extra library (and thus extra patching for working in Ubuntu) is unpleasant. Shouldn't this case be covered by the Notification Spec and each desktop offer a standard single mechanism for handling them, independently of the app? Shouldn't the Messaging Menu drop the messaging app requirement and become the standard Ubuntu mechanism for handling these kind of notifications? For the sake of consistency and for the sake of not driving upstream crazy, I do believe that this case should be well-specified in libnotify, and the manipulation of something like the messaging menu, should be part of NotifyOSD. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Merging libindicate into libnotify
The existence of libindicate is something that has always bothered me. The not-necessarily-immediate-response case is a common scenario required by a significative number of applications, and requiring those applications to support an extra library (and thus extra patching for working in Ubuntu) is unpleasant. Shouldn't this case be covered by the Notification Spec and each desktop offer a standard single mechanism for handling them, independently of the app? Shouldn't the Messaging Menu drop the messaging app requirement and become the standard Ubuntu mechanism for handling these kind of notifications? This is something that _is_ covered by a particular subset of the notification specification; it's just that it isn't guaranteed. Gnome Shell is doing what you want here: they went ahead and defined persistent notifications, which their message tray is optimised for. Unfortunately, it's all wrapped into the same notification specification for some reason. The platform as a whole now has an impressively convoluted setup for notifications. It's almost as if we don't want people using these. Here's what an application must do, as I understand it: * First, I will ask the notification server for its capabilities. Does it support persistence? * Yes? Great, I'll show a resident notification. * No? Okay, just give it a long life and a few actions, I guess. * I can't do actions? Okay, change the message to reflect that, maybe tell the user where to find me. * Wait, do I even know what this notification server is doing? Ugh, it's probably notify-osd. I guess I'll assume it's a transient notification. * Am I reading the right version of the notification spec? * Well, now that I've gone this far, it can't hurt to add libindicate. Right? * Do I actually belong in the messaging menu? Don't care: I want a resident notification, and my developers don't want to maintain any more strings! * The end. Android does this well: http://developer.android.com/guide/topics/ui/notifiers/index.html There is no overlap. Each type of notification is optimised for one task. You choose, from the onset, if you want a Toast notification, a Status Bar notification, or a dialog notification. Each one does exactly what it says on the tin and it does it well. An application doesn't waste resources trying to figure out how to present a notification at runtime and the system knows exactly how each type of notification is meant to be displayed. Perhaps there is room for consolidating Ubuntu's great work on transient notifications and Gnome's great work on persistent notifications by managing these as separate systems with their own specifications. Because, as the messaging menu pretty clearly reminds us, they are. Dylan ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Merging libindicate into libnotify
Le jeudi 31 mars 2011 à 12:35 -0700, Dylan McCall a écrit : This is something that _is_ covered by a particular subset of the notification specification; it's just that it isn't guaranteed. Gnome Shell is doing what you want here: they went ahead and defined persistent notifications, which their message tray is optimised for. Unfortunately, it's all wrapped into the same notification specification for some reason. The platform as a whole now has an impressively convoluted setup for notifications. It's almost as if we don't want people using these. Here's what an application must do, as I understand it: * First, I will ask the notification server for its capabilities. Does it support persistence? * Yes? Great, I'll show a resident notification. * No? Okay, just give it a long life and a few actions, I guess. * I can't do actions? Okay, change the message to reflect that, maybe tell the user where to find me. * Wait, do I even know what this notification server is doing? Ugh, it's probably notify-osd. I guess I'll assume it's a transient notification. * Am I reading the right version of the notification spec? * Well, now that I've gone this far, it can't hurt to add libindicate. Right? * Do I actually belong in the messaging menu? Don't care: I want a resident notification, and my developers don't want to maintain any more strings! * The end. Android does this well: http://developer.android.com/guide/topics/ui/notifiers/index.html There is no overlap. Each type of notification is optimised for one task. You choose, from the onset, if you want a Toast notification, a Status Bar notification, or a dialog notification. Each one does exactly what it says on the tin and it does it well. An application doesn't waste resources trying to figure out how to present a notification at runtime and the system knows exactly how each type of notification is meant to be displayed. Perhaps there is room for consolidating Ubuntu's great work on transient notifications and Gnome's great work on persistent notifications by managing these as separate systems with their own specifications. Because, as the messaging menu pretty clearly reminds us, they are. In my opinion, separating the systems is not necessary, and wrapping all cases in the same specification is not a bad thing. The main problem is, as you pointed out, this GetCapabilities mess. The applications should not *care* whether the server supports persistence or not: it should just say that the notification is supposed to persist. Whether the server will do this competently, is not the applications' problem. But save for this GetCapabilities issue, the specification is fine. The serves are broken. Gnome3 is too optimized for persistent notifications, while Ubuntu is too optimized for transient notifications. Ideally, someone developing an application for Ubuntu should not worry about using something like libindicate: he should use only libnotify, and NotifyOSD would be responsible for throwing persistent notifications to something like the messaging menu. The problem with the current implementation is: NotifyOSD simply *ignores* actions and it's up to the application developer to explicitly include libindicate support in his app. Worse: he can only do that if he can argue that his app fits in the messaging application concept. This has left this weird conceptual gap in the Ubuntu desktop, where notifications that are persistent but not related to messaging have nowhere to go, and things like Jockey, PolicyKit and Apport are now as conceptually broken as they were before: only now they use AppIndicators as their playground, instead of the notification area. (I think Apport was recently changed to use popups instead, but I don't feel this is ideal either... it's not that urgent) The Messaging Menu should be refined to support *any* persistent notifications, not only from messaging applications. Only then this conceptual gap will be closed. Until that happens, we will stay either with legacy things like jockey popping up in the indicator area or with strange things like Ubuntu One being in the Messaging Menu. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
