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 565795 - Seek bar reacting to mouse click and wheel events
Seek bar reacting to mouse click and wheel events
Status: RESOLVED FIXED
Product: banshee
Classification: Other
Component: User Interface
git master
Other Linux
: Normal enhancement
: 1.x
Assigned To: Banshee Maintainers
Banshee Maintainers
: 506672 537942 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-12-27 17:36 UTC by Moritz Schallaböck
Modified: 2009-06-04 19:22 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
proposed patch (modifies 2 files) (1.85 KB, patch)
2008-12-27 17:38 UTC, Moritz Schallaböck 		needs-work Details | Review
patch for libbanshee (modifies 1 file) (417 bytes, patch)
2008-12-27 17:47 UTC, Moritz Schallaböck 		committed Details | Review
proposed patch (modifies 2 files) (1.90 KB, patch)
2008-12-27 20:00 UTC, Moritz Schallaböck 		committed Details | Review

Description Moritz Schallaböck 2008-12-27 17:36:48 UTC 
What does happen? Clicking into the seek bar doesn't do anything. Mouse wheel does nothing.

What should happen? When clicking into the seek bar, the player seeks to the clicked position within the song. Using the mouse wheel within the seek bar skips +/- 10 seconds. I also increased the size of the seek bar by 125px. (Ideally, the seek bar would grow dynamically with the available size...)
Comment 1 Moritz Schallaböck 2008-12-27 17:38:44 UTC 
Created attachment 125395 [details] [review]
proposed patch (modifies 2 files)

This implements the enhanced seek bar.
Comment 2 Moritz Schallaböck 2008-12-27 17:47:48 UTC 
Created attachment 125396 [details] [review]
patch for libbanshee (modifies 1 file)

Note: The proposed changes respect the can_seek property, ie. clicking/wheel events only result in a seek if the played track is seekable. (E.g. internet radio streams cannot seek.)

However, can_seek is not correctly set. I'm not sure, but this seems to be down to a (known?) problem in libbanshee and/or GStreamer with respects to can_seek, which is always set to true. Libbanshee contains a workaround in case the GStreamer pipeline doesn't support feature querying; however, at least for MP3 internet radio, the pipeline says it supports querying, but incorrectly says seeking is supported. The attached patch modifies libbanshee to always apply the workaround.
Comment 3 Bertrand Lorentz 2008-12-27 18:59:23 UTC 
Thanks for the patch !

Please follow the code formatting guidelines from the HACKING file : indent with spaces, space before function parenthesis, etc.
Comment 4 Moritz Schallaböck 2008-12-27 20:00:34 UTC 
Created attachment 125398 [details] [review]
proposed patch (modifies 2 files)

Sorry about the tabs. I've tried to use the space before parentheses as in the remainder of the source. Is this better?
Comment 5 Gabriel Burt 2009-01-14 01:58:14 UTC 
Wow, Gtk.Scale doesn't handle the ScrollEvent and ButtonPress already?  This will be good to have.  In the OnScrollEvent override, why does it call OnSeekRequested outside the if ()?

Use a space between methods (andArgs)

We should probably bring the seek-a-bit logic out of src/Extensions/Banshee.NowPlaying/Banshee.NowPlaying/FullscreenWindow.cs (which does 5% or 15% jump for 'slow' or 'fast' seek) into PlayerEngine or somewhere so it's consistent.
Comment 6 Gabriel Burt 2009-02-03 17:43:05 UTC 
I committed a slightly tweaked version, thanks!
Comment 7 Alexander Kojevnikov 2009-03-28 07:18:07 UTC 
*** Bug 506672 has been marked as a duplicate of this bug. ***
Comment 8 Gabriel Burt 2009-06-04 19:22:50 UTC 
*** Bug 537942 has been marked as a duplicate of this bug. ***