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 577047 - SeekSlider is not exact
SeekSlider is not exact
Status: RESOLVED FIXED
Product: banshee
Classification: Other
Component: User Interface
git master
Other Linux
: Normal trivial
: 1.x
Assigned To: Banshee Maintainers
Banshee Maintainers
Depends on: 137812
Blocks:
 
 
Reported: 2009-03-28 07:43 UTC by Alexander Kojevnikov
Modified: 2009-05-12 00:17 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Fixes the seek position when dragging the slider. (1.26 KB, patch)
2009-03-28 11:30 UTC, Alexander Kojevnikov
committed Details | Review

Description Alexander Kojevnikov 2009-03-28 07:43:32 UTC
When left clicking on the seek slider the calculated position is incorrect. The same happens when grabbing the slider's handle, dragging and dropping it.

The reason is that in SeekSlider.OnButtonReleaseEvent() when translating the clicked X coordinate into the seek value, instead of the slider's actual seeking width it takes the control's width which is slightly bigger as illustrated below:

<- width of the control ->
[-]----------------------
 ----------------------[-]
 <-    seeking width   ->

I'm not sure if it's possible to get the actual seeking width from HScale, however the middle mouse click works just fine. May be the left click should be translated to middle click (see also bug 565795 which originally requested this feature.)

Steps to reproduce:

 1. Start playing a song, longer songs will result in bigger seeking mistakes. I will use a 5:00 song as an example
 2. Grab the seek slider handle with left mouse button and drag it to about 30 second mark.
 3. The playback jumps to about 50-55 seconds.
 4. Try again, this time to the 4:30 mark.
 5. The playback jumps approximately to 4:05.
 6. Now instead of dragging the handle just click on the slider. 
 7. Notice how the handle lands to the right of the mouse cursor when you click near the beginning of the song, to the left when you click near its end, and under the cursor when you click in the middle of the song.
Comment 1 Alexander Kojevnikov 2009-03-28 10:54:41 UTC
Apparently there's an old bug in GTK+ regarding this: bug 137812. It even has a patch.

Marking this one dependent on it, feel free to edit if you have other ideas on how this can be worked around.
Comment 2 Alexander Kojevnikov 2009-03-28 11:30:59 UTC
Created attachment 131549 [details] [review]
Fixes the seek position when dragging the slider.

The patch fixes half of the problem (steps 2. to 5.) Clicking on the slider (steps 6. and 7.) is still not exact, however I think it's less annoying.
Comment 3 Gabriel Burt 2009-04-02 21:05:50 UTC
Hrm, can't we just use Adjustment.Value / (Adjustment.Upper - Adjustment.Lower) to get the exact value?  Might have to call base.OnButtonReleaseEvent first.
Comment 4 Alexander Kojevnikov 2009-04-02 22:54:49 UTC
(In reply to comment #3)
> Hrm, can't we just use Adjustment.Value / (Adjustment.Upper - Adjustment.Lower)
> to get the exact value?  Might have to call base.OnButtonReleaseEvent first.

The problem is that Adjustment.Value is not properly set when clicking on the slider, see bug 137812. The HScale widget steps/pages when it's clicked, just like the scrollbar, but we want it to jump directly to the clicked position.
Comment 5 Gabriel Burt 2009-05-12 00:00:11 UTC
Thanks Alexander
Comment 6 Alexander Kojevnikov 2009-05-12 00:17:07 UTC
Thanks, committed.

Closing the bug because fixing the other half of the problem (clicking on the slider) depends on GTK+ bug 137812.