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 164351 - Seeking with mousewheel is reversed
Seeking with mousewheel is reversed
Status: RESOLVED FIXED
Product: rhythmbox
Classification: Other
Component: User Interface
0.8.8
Other All
: Normal minor
: ---
Assigned To: RhythmBox Maintainers
RhythmBox Maintainers
: 330570 564671 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-01-17 13:21 UTC by Luca De Rugeriis
Modified: 2009-02-24 12:45 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
test reversal of seek slider when scrolling with mouse wheel (1.27 KB, patch)
2009-01-22 02:46 UTC, Neil Loknath
reviewed Details | Review
revised patch (1.84 KB, patch)
2009-01-22 18:39 UTC, Neil Loknath
committed Details | Review

Description Luca De Rugeriis 2005-01-17 13:21:47 UTC
Reverse the mouse whell action: whell up will go _forward_ in the song, whell
down will go _backwards_

Other information:
To maintain consisenty (and logic) with other apps like totem it would be nice
if the whell beahviour could be reversed.
Comment 1 James "Doc" Livingston 2005-08-23 13:38:36 UTC
From using scrolling in web browsers, word processors and the like, I've come to
associate "wheel up" with going towards the beginning and "wheel down" going
towards the end - so RB does what I expect. However other people (such as
yourself) expect "wheel up" to increase the time since the start of the song.

I'm not sure which is more common, but we should remain consistant with other
applications. Unfortunately there doesn't seem to be a consensus on which way
around it should be, even amongst the official Gnome Desktop applications.

* Totem: "Wheel Up" = forwards
* Sound Juicer: "Wheel Up" = backwards

* Gnome Sound Recorder: "Wheel Up" = forwards
* Gnome CD Player: "Wheel Up" = backwards
* Muine, amaroK and BMP can't seek with the mouse-wheel (at least the version I
have)
Comment 2 Luca De Rugeriis 2005-08-23 15:43:37 UTC
I admit I have reconsidered it, and after using other applications which behaved
like RB, I agree with the association "wheel down" --> "towards the end".
Also gtk default behaviour for scrollbars and similar is "wheel down" -->
"towards the end".
Comment 3 James "Doc" Livingston 2006-02-11 00:49:51 UTC
*** Bug 330570 has been marked as a duplicate of this bug. ***
Comment 4 Bruno Santos 2006-04-22 17:10:25 UTC
A bit OT but related to seeking, it seems that seeking is made in real time, even when I hold the seek button, that causes (also using the wheel, though) some jerkiness in seeking, weird seek jumps, playback pauses, sound missing (silent playback), etc... Is the problem with the way RB handles seeking or something to do with GST? Sorry for the OT question, I'll be searching for a related bug report  or I'll issue a new one, though. 
Comment 5 Bastien Nocera 2008-09-08 15:16:13 UTC
(In reply to comment #1)
<snip>
> * Totem: "Wheel Up" = forwards
> * Sound Juicer: "Wheel Up" = backwards
> 
> * Gnome Sound Recorder: "Wheel Up" = forwards
> * Gnome CD Player: "Wheel Up" = backwards
> * Muine, amaroK and BMP can't seek with the mouse-wheel (at least the version I
> have)

That's probably because Totem is the only application to have bothered changing the default GTK+ mouse-wheel behaviour.
Comment 6 Jonathan Matthew 2008-12-16 00:14:54 UTC
*** Bug 564671 has been marked as a duplicate of this bug. ***
Comment 7 markos 2008-12-16 01:14:39 UTC
why not able an invert option in preferences and make everybody happy?
Comment 8 Neil Loknath 2009-01-22 02:46:03 UTC
Created attachment 126960 [details] [review]
test reversal of seek slider when scrolling with mouse wheel

Here is a patch for rb-header.c that reverses the scrolling behavior.  If everyone approves, maybe we can add to the patch the option to toggle the slider direction?  This "bug" is a very small detail, however.  And, I would not be offended if this does not want to be pursued.  Although, with that being said, I would be happy to continue with this :)

Please, be gentle.  This is my first submitted patch.  

Thanks,
Neil
Comment 9 Jonathan Matthew 2009-01-22 09:04:33 UTC
A couple of minor things:
- you don't need comments to say that you've added something; in fact, I don't think any of your comments really add anything
- please try to copy the spacing and formatting of the file you're modifying.  in particular, we always include a space between the function name and its arguments.
- the first rb_debug call is unnecessary

I think we probably want to seek by more than 1 second either way per event, but I'm not sure how much.  I don't think copying the values from totem would be a good idea (+15 and -5 seconds); seems like they should be smaller than that.

We should just be consistent with totem in this respect, without making it configurable.  This just isn't important enough to warrant a configuration item.  Initially I had no real opinion on which direction would be better, but over time I've come to expect the same behaviour as totem.  It seems to be a different enough context that I don't carry an expectation over from the scrolling behaviour of documents.
Comment 10 Neil Loknath 2009-01-22 18:39:15 UTC
Created attachment 127022 [details] [review]
revised patch
Comment 11 Neil Loknath 2009-01-22 18:41:44 UTC
Comment on attachment 127022 [details] [review]
revised patch

understood.
applied your comments and modified the slider adjustment to be +/-5 instead of 1.
Comment 12 Jonathan Matthew 2009-02-24 12:45:42 UTC
2009-02-24  Jonathan Matthew  <jonathan@d14n.org>

        patch by:  Neil Loknath  <neil.loknath@gmail.com>

        * widgets/rb-header.c: (rb_header_init), (slider_scroll_callback):
        Handle scroll events on the slider to make the seek direction
        consistent with totem.  Fixes #164351.