After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 710115 - More message tray cleanups
More message tray cleanups
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2013-10-14 15:41 UTC by Jasper St. Pierre (not reading bugmail)
Modified: 2014-01-17 14:13 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
messageTray: Clean up code that determines if something is clearable (2.47 KB, patch)
2013-10-14 15:41 UTC, Jasper St. Pierre (not reading bugmail)
committed Details | Review
messageTray: Remove transient sources (7.69 KB, patch)
2013-10-14 15:42 UTC, Jasper St. Pierre (not reading bugmail)
committed Details | Review
messageTray: Move the notification policy classes here (12.41 KB, patch)
2013-10-14 15:42 UTC, Jasper St. Pierre (not reading bugmail)
committed Details | Review
messageTray: Only connect to a notification's open/destroy once (1.42 KB, patch)
2013-10-14 15:42 UTC, Jasper St. Pierre (not reading bugmail)
committed Details | Review
messageTray: Split out the notification's destroy handler (1.82 KB, patch)
2013-10-14 15:42 UTC, Jasper St. Pierre (not reading bugmail)
committed Details | Review
messageTray: Don't remove and re-add the focus group on button changes (1.65 KB, patch)
2013-10-14 15:42 UTC, Jasper St. Pierre (not reading bugmail)
committed Details | Review
messageTray: Remove reNotifyAfterHideNotification logic (2.95 KB, patch)
2013-10-14 15:42 UTC, Jasper St. Pierre (not reading bugmail)
reviewed Details | Review

Description Jasper St. Pierre (not reading bugmail) 2013-10-14 15:41:42 UTC
At the Montreal Summit, we want to land the new GNotification API which
will use a new notification specification. Do the usual cleanup work before
landing this.
Comment 1 Jasper St. Pierre (not reading bugmail) 2013-10-14 15:41:55 UTC
Created attachment 257265 [details] [review]
messageTray: Clean up code that determines if something is clearable
Comment 2 Jasper St. Pierre (not reading bugmail) 2013-10-14 15:42:01 UTC
Created attachment 257266 [details] [review]
messageTray: Remove transient sources

As far as I can tell, the only behavior change of a transient source
is that they auto-destroy after viewing their summary box pointer.
Since all transient sources are only associated with transient
notifications, it seems that we can never get to their summary box
pointer in the first place! Remove support for this.
Comment 3 Jasper St. Pierre (not reading bugmail) 2013-10-14 15:42:07 UTC
Created attachment 257267 [details] [review]
messageTray: Move the notification policy classes here

The NotificationDaemon really should be for the hookup of remote
notifications, rather than policies.
Comment 4 Jasper St. Pierre (not reading bugmail) 2013-10-14 15:42:13 UTC
Created attachment 257268 [details] [review]
messageTray: Only connect to a notification's open/destroy once

If we pushNotification the same notification multiple times, we
won't append it to the array again, but we will attach multiple
handlers needlessly.
Comment 5 Jasper St. Pierre (not reading bugmail) 2013-10-14 15:42:19 UTC
Created attachment 257269 [details] [review]
messageTray: Split out the notification's destroy handler

This is complex enough to split out.
Comment 6 Jasper St. Pierre (not reading bugmail) 2013-10-14 15:42:27 UTC
Created attachment 257270 [details] [review]
messageTray: Don't remove and re-add the focus group on button changes
Comment 7 Jasper St. Pierre (not reading bugmail) 2013-10-14 15:42:34 UTC
Created attachment 257271 [details] [review]
messageTray: Remove reNotifyAfterHideNotification logic

When we hide the summary box pointer, we always drop to the tray
instead of the desktop, so this code would simply drop the notification
anyway.
Comment 8 Giovanni Campagna 2013-10-14 16:53:58 UTC
Review of attachment 257265 [details] [review]:

::: js/ui/messageTray.js
@@ +1546,3 @@
         this._clearItem = this.addAction(_("Clear Messages"), function() {
+            let toDestroy = tray.getSources().filter(function(source) {
+                return source.isClearable();

Not a function call.
Comment 9 Giovanni Campagna 2013-10-14 16:56:22 UTC
Review of attachment 257266 [details] [review]:

The analysis is wrong, a summary box pointer can appear for a transient source if a transient notification is emitted while interacting with the message tray, so this is a behavior change.
Also, this merges transient notifications with resident and persistent ones, which is not quite what the commit message says.
Comment 10 Giovanni Campagna 2013-10-14 16:57:57 UTC
Review of attachment 257267 [details] [review]:

I thought the split was "NotificationDaemon for application notifications, MessageTray internal API", but ok for me either way.
Comment 11 Giovanni Campagna 2013-10-14 16:58:47 UTC
Review of attachment 257268 [details] [review]:

Yes
Comment 12 Giovanni Campagna 2013-10-14 16:59:17 UTC
Review of attachment 257269 [details] [review]:

Sure
Comment 13 Giovanni Campagna 2013-10-14 17:01:29 UTC
Review of attachment 257270 [details] [review]:

Ok
Comment 14 Giovanni Campagna 2013-10-14 17:03:39 UTC
Review of attachment 257271 [details] [review]:

No, it would put the notification in the queue after the end of the animation, which seems more correct that acknowledging the notification without the user seeing it.
Comment 15 Jasper St. Pierre (not reading bugmail) 2013-10-14 19:24:15 UTC
(In reply to comment #9)
> The analysis is wrong, a summary box pointer can appear for a transient source
> if a transient notification is emitted while interacting with the message tray,
> so this is a behavior change.

That is true, but the notification will be queued while the tray was up, and will display after it collapses

> Also, this merges transient notifications with resident and persistent ones,
> which is not quite what the commit message says.

Yes, we drop the code that creates new sources if the app already exists. I'm not aware of any apps sending transient notifications -- they should simply be for system sources, so I'm not sure why that matters.

Keep in mind that I don't remove transient notifications, only transient sources.
Comment 16 Jasper St. Pierre (not reading bugmail) 2013-10-14 19:25:50 UTC
Attachment 257265 [details] pushed as da14e2c - messageTray: Clean up code that determines if something is clearable
Attachment 257267 [details] pushed as 66a4cb5 - messageTray: Move the notification policy classes here
Attachment 257268 [details] pushed as 99cf4e5 - messageTray: Only connect to a notification's open/destroy once
Attachment 257269 [details] pushed as 25fd23e - messageTray: Split out the notification's destroy handler
Attachment 257270 [details] pushed as 96aa33f - messageTray: Don't remove and re-add the focus group on button changes


Let's push all of these for now. Fixed the issue with isClearable in the first patch.
Comment 17 Jasper St. Pierre (not reading bugmail) 2013-12-05 01:25:53 UTC
Comment on attachment 257266 [details] [review]
messageTray: Remove transient sources

Attachment 257266 [details] pushed as b52e74b - messageTray: Remove transient sources