GNOME Bugzilla – Bug 687016
Revert recent closing changes
Last modified: 2013-09-02 22:39:18 UTC
We should revert the commits: http://git.gnome.org/browse/gnome-shell/commit/?id=71c23613b5e3d05a4c2bf3a0cf7d62e5268cb417 and http://git.gnome.org/browse/gnome-shell/commit/?id=92a01c67ba17858b048e335c75b9b328695a41b4 This makes no sense ... the user explicitly closed the notification so we should honor this request and not clutter the message tray with useless icons. While for some notifications (like chats) having them around longer makes sense, for pretty much all other non resident notifications this change just causes more work for the user (rightclick and close on the source) or just have a clutter tray after some time. The comment by jimmac said that we should remove them once the tray is closed, as we no longer open the tray while the notification is visible there is no icon that suddenly disappears (in front of the user) when closing the notification. So in addition to the change not making much sense to me in the first place the justification for it is gone as well so we should just revert those changes.
Created attachment 227444 [details] [review] Revert "messageTray: Only hide the notification stack on clicking close" This makes no sense. https://bugzilla.gnome.org/show_bug.cgi?id=687016 This reverts commit 71c23613b5e3d05a4c2bf3a0cf7d62e5268cb417.
Created attachment 227445 [details] [review] Revert "messageTray: Don't destroy the notification when clicking on the close button" This makes no sense. https://bugzilla.gnome.org/show_bug.cgi?id=687016 This reverts commit 92a01c67ba17858b048e335c75b9b328695a41b4.
Did you talk with someone (designers, maintainers) in IRC about this? This is going nowhere without their approval, and bugzilla is not a discussion forum. (I do agree with you that the purpose of close is, well, to close the notification, like good old notification-daemon did)
(In reply to comment #3) > Did you talk with someone (designers, maintainers) in IRC about this? > This is going nowhere without their approval, and bugzilla is not a discussion > forum. I have tried but got no response yet, so I decide to file it so it does not get lost.
See the rationale in bug #682237.
(In reply to comment #5) > See the rationale in bug #682237. Saw it ... it no longer applies. "but the point remains in that closing a bubble while in the message tray should not remove/destroy the source as well as the bubble. It's very indirect and unexpected. I operate on the bubble and suddenly an icon disappears (and the whole message tray closes)." We don't show the messagetray when a notification is displayed ... also the close "x" button pretty much everywhere means "destroy" not "hide". We don't leave apps open when you close the last window either ... it just does not make any sense. So the changes still don't make sense -> should get reverted.
(In reply to comment #6) > We don't show the messagetray when a notification is displayed ... Allan was talking about opening the message tray, and then closing a bubble. We kill the source, and then close the message tray. In that context, the more likely scenario is that the user simply wanted to close the bubble, not kill the source icon. > also the > close "x" button pretty much everywhere means "destroy" not "hide". We don't > leave apps open when you close the last window either ... it just does not make > any sense. You're destroying the bubble, not the notification. Note that this is in Windows and the old notification-daemon, too: clicking "X" on a bubble that pops up will not kill the source.
(In reply to comment #6) > (In reply to comment #5) > > See the rationale in bug #682237. > > Saw it ... it no longer applies. That is wrong. The designers filed bug #682237 *after* the message tray redesign landed. You are free to disagree with the design, but the argument that the reasoning in the bug no longer applies is invalid.
(In reply to comment #7) > (In reply to comment #6) > > We don't show the messagetray when a notification is displayed ... > > Allan was talking about opening the message tray, and then closing a bubble. We > kill the source, and then close the message tray. In that context, the more > likely scenario is that the user simply wanted to close the bubble, not kill > the source icon. The user have read the notification and clicked on close. Why clutter the tray with it? The right click close thing is not the most obvious thing to do and the user shouldn't have to "clean up" the tray by hand. > > also the > > close "x" button pretty much everywhere means "destroy" not "hide". We don't > > leave apps open when you close the last window either ... it just does not make > > any sense. > > You're destroying the bubble, not the notification. Note that this is in > Windows and the old notification-daemon, too: clicking "X" on a bubble that > pops up will not kill the source. From a users POV the bubble *is* the notification.
(In reply to comment #8) > (In reply to comment #6) > > (In reply to comment #5) > > > See the rationale in bug #682237. > > > > Saw it ... it no longer applies. > > That is wrong. The designers filed bug #682237 *after* the message tray > redesign landed. You are free to disagree with the design, but the argument > that the reasoning in the bug no longer applies is invalid. OK let me reword that "it only applies for the case where you interact with the summary area and even then it is questionable".
I'm sympathetic with the argument that we don't want to make more cleanup work for users. That said... * The close buttons have to behave consistently for banners and for the bubbles that pop up from the tray, and it *really* doesn't make sense for the latter to remove the tray item. and... * Pressing a close button doesn't necessarily mean that someone has finished with a notification - it may simply be that they don't want to see it right now, but do want it to hang around so they can act on it in the future.
(In reply to comment #11) > I'm sympathetic with the argument that we don't want to make more cleanup work > for users. That said... > > * The close buttons have to behave consistently for banners and for the > bubbles that pop up from the tray, and it *really* doesn't make sense for the > latter to remove the tray item. > > and... > > * Pressing a close button doesn't necessarily mean that someone has finished > with a notification - it may simply be that they don't want to see it right > now, but do want it to hang around so they can act on it in the future. That still means that icons will accumulate over time so that at some point the user will have to clean up. And there is no obvious way how to do so (the right click menu is rather obscure). We could have a hide and a close button i.e "keep for later" and "don't want". We also destroy the notification on click. Which is weird really. When I click on a notification it gets destroyed but when I use the explicit close button it will just get hidden?
Clicking on the body of the notification or pressing any buttons (etc) it might contain will still dismiss the message - this is our primary way in which we know that the notification has been acted on. We'll see how things go, and it might be possible to add an action that clears all non-resident notifications from the tray, but this still seems the safest option in terms of being consistent with expected behaviour.
(In reply to comment #13) > Clicking on the body of the notification or pressing any buttons (etc) it might > contain will still dismiss the message - this is our primary way in which we > know that the notification has been acted on. Not really "click to dismiss" never made much of sense. It can happen by accident while the close button is an explicit action (same as the buttons). > We'll see how things go, and it might be possible to add an action that clears > all non-resident notifications from the tray, but this still seems the safest > option in terms of being consistent with expected behaviour. Well a close button that acts like "hide" is not what I would call "expected behavior". A "cleanup" button somewhere in the tray? Even this would kind of suck because we would still ask the user to do something that we (as in the computer) can do for him. Can we just swap the two actions? Click = hide ; close = destroy ?
(In reply to comment #14) > (In reply to comment #13) > > Clicking on the body of the notification or pressing any buttons (etc) it might > > contain will still dismiss the message - this is our primary way in which we > > know that the notification has been acted on. > > Not really "click to dismiss" never made much of sense. It can happen by > accident while the close button is an explicit action (same as the buttons). It's "click to acknowledge" rather than "click to dismiss", given that we do a bit more than removing the notification: the default action (if any) and the corresponding application (if any) are activated. > A "cleanup" button somewhere in the tray? Even this would kind of suck because > we would still ask the user to do something that we (as in the computer) can do > for him. I agree that we could do better in cleaning out the tray automatically, but to be fair, we already do in a lot of cases. Services should explicitly close notifications that no longer apply (e.g. gsd closes the low battery warning when on A/C), and an application's notifications are closed when the application is focused. We have chat notifications that stick around forever, but that's a bug (657278). > Can we just swap the two actions? Click = hide ; close = destroy ? I'm not sure we can do so easily. Directly swapping the two does not make much sense - switching application focus on clicking the close button would be utterly weird. But even when just swapping the close/hide behavior, I'm not sure about the result - we'd end up with dismissing a (potentially unread) notification being more destructive than acknowledging it (except when the latter also removes the notification, which would be the case when we have an associated application to focus). Not to mention that again the only way to dismiss a notification temporarily would be to move the pointer in and out of the notification ...
This change has just hit me too. The new behaviour seems bizarre and counter intuitive. I quite often have notifications with URLs in them which makes it hard to trigger the "click to dismiss" sometimes, so when I see such a notification, I typically use the close button to get rid of it. I just went on IRC to ask if anyone had seen this bug and was directed here. If you want the close button to just hide the window but not kill it off, what does will you make the exact same close button do on windows when viewing the shell overview? These buttons have always killed the window and closed the application. Is this behaviour going to change or are you all happy to have inconsistent behaviour for the exact same icon?
Created attachment 249811 [details] [review] message-tray: Really notifications when the close button is clicked When the user eclipictly closes a notification, we should really destroy it not just move it to the tray. --- This time with design support: https://wiki.gnome.org/GnomeOS/Design/Whiteboards/Notifications "Press the close button: closes the notification and removes it from the Message Tray. "
Created attachment 249812 [details] [review] message-tray: Really close notifications when the close button is clicked When the user eclipictly closes a notification, we should really destroy it not just move it to the tray. --- Fix subject
Review of attachment 249812 [details] [review]: ::: js/ui/messageTray.js @@ +1428,3 @@ + source.destroy(); + source.emit('done-displaying-content'); + })); This is for summary notifications, not for banner - not covered by the new designs. (This is arguably a design bug)
Attachment 249812 [details] pushed as f4100ac - message-tray: Really close notifications when the close button is clicked
*** Bug 691953 has been marked as a duplicate of this bug. ***