GNOME Bugzilla – Bug 612072
Rhythmbox notifications getting bigger and bigger
Last modified: 2010-05-10 13:45:59 UTC
When I change to the next song in Rhythmbox, a discrete notification appears in Gnome-Shell. If I move the mouse on it, then it gets a little bigger and a « next » button appears (this is great by the way). Now, each time I change song in Rhythmbox (or if I let it change automatically when a song is finished), I have the same nice and discrete notification, but if I move my mouse on it, it gets a little bigger for each song passed. It's like it adds one more line to the popup each time. I can provide screenshots if the description is not clear enough. gnome-shell-2.28.0-3.10.6423cbfc92ac4c59e250a08d63226df38df04d96.fc12.x86_64 (from http://fedorapeople.org/~walters/gnome-shell-F12/) rhythmbox-0.12.6-3.fc12.x86_64
This causes a second issue : by the time the notification reaches the top of the screen, it becomes persistent, i.e it won't ever disappear when moving the mouse away from it. At this point, the only way I found to get rid of it is to terminate my session (entering « r » in the alt+F2 dialog doesn't restart Gnome-Shell here, it crashes my session). This is with gnome-shell-2.28.0-3.124.20100325gitd173f9e1.fc12.x86_64 from walters' repository.
the growing bug should probably get fixed by the notification layout changes in bug 608999. the other thing: (In reply to comment #1) > This causes a second issue : by the time the notification reaches the top of > the screen, it becomes persistent, i.e it won't ever disappear when moving the > mouse away from it. actually happens all the time (the space to the left and right of the expanded notification is reactive, rather than just the notification itself), it's just that normally you can get around it by moving to above the notification
Created attachment 157208 [details] [review] MessageTray: tweak how allocation works to fix the reactive area Rather than having the notificationBin, summaryBin, and summaryNotificationBin span the whole width of the screen and just align their children to the right spot, set their anchor_gravity appropriately, set their anchor point correctly, and let their width vary with the width of their child. Fixes the fact that the area to the left and right of an expanded notification was reactive, because the notificationBin was invisibly covering it. (Depends on bug 614047; the message-tray-fixing part can be tested without that, but the summary area will disappear...)
Review of attachment 157208 [details] [review]: Interesting, I hadn't been considering use of the anchor point in places where I probably could have; I've normally implemented a container instead. But this looks good.
Comment on attachment 157208 [details] [review] MessageTray: tweak how allocation works to fix the reactive area Attachment 157208 [details] pushed as 611ca3c - MessageTray: tweak how allocation works to fix the reactive area
From your last messages, I get it that you only fixed the fact that the huge notification will still be able to disappear (changed the reactive area), but not the fact that it gets bigger in the first place. Well I don't know what happened, but now the notification always remain the appropriate size, so this bug seems to be fixed anyway :) # yum --disablerepo=gnome-shell list extras | grep '@gnome-shell' clutter.x86_64 1.0.6-1.24.20100331gitfdf608af.fc12 @gnome-shell gir-repository.x86_64 0.6.5-3.11.20100318git4c7c6d09.fc12 @gnome-shell gjs.x86_64 0.4-1.12.20100330git133dd0ac.fc12 @gnome-shell gnome-shell.x86_64 2.28.0-3.149.20100404gitbae07700.fc12 @gnome-shell gobject-introspection.x86_64 0.6.5-1.19.20100325gitf81ef828.fc12 @gnome-shell mutter.x86_64 2.28.0-2.23.20100330git0d955bb8.fc12 @gnome-shell
ah, well, I couldn't figure out why it was growing anyway, so probably that had already been fixed in git by something else before I looked at it.
I'm reopening this bug as the problem is back with gnome-shell-2.29.1-4.x86_64 in F13. Notification grows bigger and bigger, and the notification doesn't disappear if I move my mouse on the side of it, which means once it reaches the top there is now way to make it disappear anymore.
(In reply to comment #8) > I'm reopening this bug as the problem is back with gnome-shell-2.29.1-4.x86_64 > in F13. This is older than most of the discussion above (dates from Mar 27)
closing per above comment