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 607244 - Don't show the empty messagetray
Don't show the empty messagetray
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2010-01-17 19:12 UTC by drago01
Modified: 2010-02-15 15:14 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Don't show the empty messagetray (1.00 KB, patch)
2010-01-17 19:12 UTC, drago01
none Details | Review
[messagetray] Activate using the lower right corner instead bottom of the screen (2.92 KB, patch)
2010-02-03 20:49 UTC, drago01
needs-work Details | Review
[messagetray] Trigger only using the lower right corner when empty (2.89 KB, patch)
2010-02-08 15:47 UTC, drago01
needs-work Details | Review
[MessageTray] Limit activation to summary area and notifications (3.99 KB, patch)
2010-02-09 17:15 UTC, drago01
none Details | Review
fixes (2.45 KB, patch)
2010-02-09 18:20 UTC, Dan Winship
none Details | Review
[MessageTray] Limit activation to summary area and notifications (4.58 KB, patch)
2010-02-09 18:35 UTC, drago01
committed Details | Review

Description drago01 2010-01-17 19:12:11 UTC
Currently the messagetray is always shown the the mouse hits the bottom of the screen; even when it contains no data at all.

This doesn't make much sense i.e it is pointless and annoying.

The attached patch fixes this by only bringing it to front when it actually contains data to view.
Comment 1 drago01 2010-01-17 19:12:39 UTC
Created attachment 151617 [details] [review]
Don't show the empty messagetray
Comment 2 Luis Medinas 2010-01-18 18:43:00 UTC
I agree this is very annoying specially when the user needs to resize windows or using bars on firefox and other apps.
Comment 3 Owen Taylor 2010-01-18 21:19:59 UTC
I'm not sure about the usability aspects here - things are supposed to linger in the message tray (I think conversations icon stay around for 5 minutes; your music will stay there as long as you are playing music, etc.)

So, we can't count on the tray not being there to make it not annoying. You might have a tray there the whole day.

Also, because you "go to the tray" to get back to a conversation, review your currently playing track or stop it, etc, I think it might be confusing if it sometimes didn't pop up - you might feel like you aren't doing it right, or that it's broken, instead of quickly seeing "it's empty".

I wonder if it would work to restrict mouse-over popping up to the right corner -where the icons appear. (Maybe the center portion would work for15 seconds after a notification slid back down, but not normally. You could even have a small visual indicator when the center would work - like the very top of the notification bubble. Then that vanishes after the 15 seconds.)
Comment 4 drago01 2010-01-18 21:33:29 UTC
(In reply to comment #3)
> I'm not sure about the usability aspects here - things are supposed to linger
> in the message tray (I think conversations icon stay around for 5 minutes; your
> music will stay there as long as you are playing music, etc.)
> 
> So, we can't count on the tray not being there to make it not annoying. You
> might have a tray there the whole day.
> 
> Also, because you "go to the tray" to get back to a conversation, review your
> currently playing track or stop it, etc, I think it might be confusing if it
> sometimes didn't pop up - you might feel like you aren't doing it right, or
> that it's broken, instead of quickly seeing "it's empty".
> 
> I wonder if it would work to restrict mouse-over popping up to the right corner
> -where the icons appear. (Maybe the center portion would work for15 seconds
> after a notification slid back down, but not normally. You could even have a
> small visual indicator when the center would work - like the very top of the
> notification bubble. Then that vanishes after the 15 seconds.)

It simply does not make sense to show an empty bar every time you hit the bottom, besides I think it should "grow as needed" instead to always be as width as the screen when 90% of the bar is empty anyway.

If we really want it to "always be present" than something like a bottom panel would be more suited imho (i.e just be always there instead of auto hide), that way it don't disturb the interaction with other apps like it does now.
Comment 5 William Jon McCann 2010-01-22 01:02:03 UTC
Agree completely with Owen's comment.  If we are finding that the tray is greatly interfering with things we may want to try to restrict it to the corner when not following a notification.  That sorta makes sense anyway since to do anything with them you have to then slide over to the right anyway.  Especially since we do the summary reminder after notifications.  

This doesn't help you find he resize grib on maximized windows but I'm not sure how interesting that is. I think we want to be able to just grab the window titlebar in that case.
Comment 6 Jonathan Matthew 2010-01-22 01:21:59 UTC
If the problem is that the empty message tray is confusing or inscrutable, maybe the answer is for it to never be empty.  I don't have any particularly good ideas about how to do that though - email?  weather?  system updates?
Comment 7 Dan Winship 2010-01-22 16:17:46 UTC
(In reply to comment #5)
> This doesn't help you find he resize grip on maximized windows but I'm not sure
> how interesting that is. I think we want to be able to just grab the window
> titlebar in that case.

epiphany and gedit both hide the resize grip when the window is maximized. Firefox doesn't, but the resize grip doesn't *work* when the window is maximized. Probably metacity doesn't allow it? So...
Comment 8 Jasper St. Pierre (not reading bugmail) 2010-01-23 20:18:29 UTC
I think the optimal way to solve this would be to make the bar appear, but have it be translucent when you aren't hovering in the area where icons are, and click-throughable, like notify-osd's notifications.
Comment 9 drago01 2010-02-03 20:49:44 UTC
Created attachment 152965 [details] [review]
[messagetray] Activate using the lower right corner instead bottom of the screen

Currently the messagetray shows up everytime the mouse hits the bottom of the screen, which results into it being activated most of the time without the user intending to do so.
Comment 10 drago01 2010-02-07 13:39:52 UTC
Comment on attachment 152965 [details] [review]
[messagetray] Activate using the lower right corner instead bottom of the screen

OK, this seems to break the "slide out" feature.
Comment 11 Dan Winship 2010-02-08 14:57:54 UTC
Comment on attachment 152965 [details] [review]
[messagetray] Activate using the lower right corner instead bottom of the screen

>+        this._hotCorner = new Clutter.Rectangle({ x: primary.x + primary.width - 1,

>+        this._hotCorner.x = primary.x + primary.width - 1;

this part is definitely wrong; this._hotCorner is inside the tray actor, which is itself located at x=primary.x. So you don't want to add primary.x to this._hotCorner.x as well; it should just be 0.
Comment 12 Dan Winship 2010-02-08 14:58:32 UTC
um, where by "0" I mean "this.actor.width - 1"
Comment 13 drago01 2010-02-08 15:23:48 UTC
(In reply to comment #11)
> (From update of attachment 152965 [details] [review])
> >+        this._hotCorner = new Clutter.Rectangle({ x: primary.x + primary.width - 1,
> 
> >+        this._hotCorner.x = primary.x + primary.width - 1;
> 
> this part is definitely wrong; this._hotCorner is inside the tray actor, which
> is itself located at x=primary.x. So you don't want to add primary.x to
> this._hotCorner.x as well; it should just be 0.

That makes sense, for some odd reason it was there where it should (i.e at the lower right corner).

But still have to find out why it breaks the slide out feature.
Comment 14 drago01 2010-02-08 15:47:10 UTC
Created attachment 153271 [details] [review]
[messagetray] Trigger only using the lower right corner when empty

Only allow triggering using the bottom of the screen when it actually contains messages,
but allow opening everytime the lower right corner is hit.

This way the annoying behaviour is fixed (open by accident), while at the same time we preserve the option to always show it.

We still need to fix the "dead icons" issue (i.e icons should not show up when they don't trigger any actions anyway).
Comment 15 Dan Winship 2010-02-09 14:35:23 UTC
Comment on attachment 153271 [details] [review]
[messagetray] Trigger only using the lower right corner when empty

>Only allow triggering using the bottom of the screen when it actually contains messages,
>but allow opening everytime the lower right corner is hit.

"contains messages" here seems to mean "the summary area is non-empty", but I don't think that's a good heuristic. Some things are likely to end up being there more-or-less permanently, in which case the patch would end up having no effect. And if you want to interact with the summary area, you're going to move the mouse down near the right corner anyway... so I think we might want to always require hitting the corner (except for the case of expanding an already-shown-but-collapsed notification in the notification area, which you should be able to do by hitting anywhere in the message tray).

Alternatively, maybe instead of having a separate hotCorner object, you could just use this._summary. Then the tray would be shown if you hit the bottom of the screen anywhere in the summary area, but not if you hit the bottom-middle or bottom-left...

>+        this._hotCorner = new Clutter.Rectangle({ x: primary.x + this.actor.width - 1,

This causes a warning:

(mutter:31759): St-WARNING **: st_widget_get_theme_node called on a widget not in a stage

and is unnecessary anyway; when the tray is allocated, _setSizePosition() will be called and then this._hotCorner will be positioned correctly.

>+        this._hotCorner.x = primary.x + this.actor.width - 1;

This is still wrong; it only works for you because primary.x is 0. You just want "this.actor.width - 1".

>+        if (!this._trayActive && JSON.stringify(this._sources) == "{}")
>+            return;

um... that is totally not the right way to check that this._sources is empty, but anyway we probably don't want that check anyway.

I don't like "_trayActive" either. I would rename _onMessageTrayEntered() to something like _showMessageTray, and then have hotCorner's enter-event handler call that method, and have this.actor's enter-event handler only call it if there was a notification showing.
Comment 16 drago01 2010-02-09 17:15:04 UTC
Created attachment 153345 [details] [review]
[MessageTray] Limit activation to summary area and notifications

Fixed up patch:

Currently the messagetray opens up everytime the user hits the bottom of the screen.

To avoid this "opening by accident" this patch changes the behaviour so that:
1) It only opens when there is a notification showing or
2) When the user hits the summary area (assuming he wants to interact with it)
Comment 17 Dan Winship 2010-02-09 18:20:14 UTC
Created attachment 153352 [details] [review]
fixes

Looks good. Just squash the attached fixes into your patch and then
commit it

  - Don't initially hide summaryBin. (Fixes it so you can show the
    summary even before the first notification arrives.)

  - Trigger on entering this._summary, not this._summaryBin, so
    that only the area above the icons is active, not the entire
    right 1/3 of the screen. (Due to padding in this._summary,
    it still has width even when it's empty, so the corner at least
    is always active.)

  - Fix y coordinate when animating, so that the summary doesn't end
    up a few pixels below the top of the message tray after it hides,
    making it impossible to trigger
Comment 18 drago01 2010-02-09 18:35:08 UTC
Created attachment 153354 [details] [review]
[MessageTray] Limit activation to summary area and notifications

Thanks commited attached one as 8ded91e.
Comment 19 Luis Medinas 2010-02-09 22:14:03 UTC
I've tried the patch and it works great, now it makes much more sense to me the actual behavior (git master). But still i found you pick the wrong "hot" corner, it should be placed on the opposite side.

See this user case:
A user have totem but it wants to expand the window without maximize (and inverse operation). The shell should be able to let the user do this.
Comment 20 Dan Winship 2010-02-15 15:14:04 UTC
reclosing this bug. if you want to file a new bug suggesting that the summary should be moved to the left corner, you can