GNOME Bugzilla – Bug 544592
Mouse-over notification bubble should only hide after a timeout
Last modified: 2009-08-18 23:39:19 UTC
The mouse-over notification hides as soon as mouse moves away from the tray icon. It should hide after a timeout, more like the on-track-change notification bubble does. It should also allow to seek, show bigger cover (as is the case with the small cover art in the main UI) and show / allow changing of the song's rating (more here: #544590) Other information:
It's true, the notification has a seek bar which makes you think you would be able to use it for something, but mousing over the notification makes the notification go away. Seems strange.
Actually, it looks like the most significant part of this bug (notification should stay up longer so you can play with the seek bar) is already covered in bug #536534 . Does that make this one a dupe?
(In reply to comment #2) > Does that make this one a dupe? I think so, looks like this one can be closed.
They are actually about different ballons - the one you get when a song changes and the one you get when you mouseover the icon. Let's keep them both open for now.
Created attachment 132237 [details] [review] Delay Hiding of Notification Bubble this is a patch for /svn/banshee/src/Extensions/Banshee.NotificationArea/Banshee.NotificationArea/X11NotificationAreaBox.cs. The delay I used is up for debate: 10 seconds? This patch is tied to http://bugzilla.gnome.org/show_bug.cgi?id=544590. However, even without the patch for #544590, this one is still useful for song seeking. #544590 still needs work to apply rating changes to the database.
Created attachment 132381 [details] [review] needs to prevent addition of delay if one exists patch was incomplete. this update is also included in patch for bug http://bugzilla.gnome.org/show_bug.cgi?id=544590
Created attachment 135648 [details] [review] Don't hide the track info popup while it has focus (Neil wrote in bug 544590) > - instead of delaying hiding of tooltip for 10 seconds, delay it long enough > (maybe 1 sec) so that the user can set the mouse pointer over the tooltip. > - when tooltip has focus, keep it up for the duration that it is in focus (have > to make sure it updates if track changes!!). > - as soon as the tooltip no longer has focus, hide it. Neil, the patch should do this. Cheers, Alex
(In reply to comment #4) > They are actually about different ballons - the one you get when a song changes > and the one you get when you mouseover the icon. Let's keep them both open for > now. > Actually they are about the same balloon - TrackInfoPopup. Here's the commit Alexander mentions in bug 536534: http://git.gnome.org/cgit/banshee/commit/?id=8ad8e0f9d10af8da7207f983a4f0a7ebc633ce62 The other balloon is shown when the currently playing track changes and it has no seek slider at all, only the track information and the skip button (in Ubuntu 9.04 it doesn't even have the button because of the new NotifyOSD)
*** Bug 536534 has been marked as a duplicate of this bug. ***
Nice, Alex. It's working well for me. I'll try and use this for the ratings patch I made for http://bugzilla.gnome.org/show_bug.cgi?id=544590.
Small nitpick: If a drop down menu is left open and the mouse focus is moved over to the tray icon to bring up the pop up, moving the focus to the pop up does not keep it open. By the way, bug 544590 has been updated with a new patch. Enjoy, Neil
(In reply to comment #11) > Small nitpick: > If a drop down menu is left open and the mouse focus is moved over to the tray > icon to bring up the pop up, moving the focus to the pop up does not keep it > open. Hmm, apparently the pop up never receives the EnterNotifyEvent after the drop down menu is opened. I guess this is intentional, try to open a drop down menu in any gtk app and move the mouse within the application window - the controls don't react to the mouse movements at all. The same is true for the pop ups from the notification area. For example, if I open Totem, right-click in its window, then move the mouse over the Banshee's notification icon - the pop up does not appear. The only exception is Banshee itself, if the drop down is open inside Banshee, either in the main window or in the notification area icon, then the pop up is shown. I will open a new bug for this.
(In reply to comment #12) > I will open a new bug for this. Filed as bug 584997.
Hey Alexander, Why do you need to do the Intersects check - why can't you always assume the LeaveNotify should start the timeout? Did you find in your testing that there were cases it didn't intersect?
(In reply to comment #14) > Hey Alexander, > > Why do you need to do the Intersects check - why can't you always assume the > LeaveNotify should start the timeout? Did you find in your testing that there > were cases it didn't intersect? > Yep, when the mouse is over the ClassicTrackInfo display, the popup receives a LeaveNotifyEvent.
Ok, thanks
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.
*** Bug 592133 has been marked as a duplicate of this bug. ***
Hey Bertrand thanks for attending to my bug so quickly. My bug was about internet radio, and that the slider doesn't make sense in that context (as you can't jump back and forth in the stream). I am wondering, does Alexander's fix account for this special case?
(In reply to comment #19) > Hey Bertrand thanks for attending to my bug so quickly. > > My bug was about internet radio, and that the slider doesn't make sense in that > context (as you can't jump back and forth in the stream). I am wondering, does > Alexander's fix account for this special case? Nope, it doesn't. But as Bertrand mentioned in bug 592133: > While streaming, the slider in the popup behaves just like the slider > in the main UI.