GNOME Bugzilla – Bug 558659
In mousewheel event, do horizontal scroll when no vertical scroll is available in a gtkscrolledwindow
Last modified: 2018-05-02 14:36:58 UTC
Hi!, nautilus has recently added a "compact view" that is like traditional icon view but it has no vertical scrollbar, instead the icons are spread horizontally so the horizontal scrollbar is in most cases present. We have a request in nautilus (bug 555571) that the compact view could be scrolled horizontally with the mouse wheel, this is a common sense behaviour because there's no vertical scroll available, so the mousewheel should do a horizontal scroll instead. As nautilus uses GtkScrolledWindow for the compact view, I'm attaching a patch here, and also because imho this behaviour should be default in any GtkScrolledWindow, that is, make the mouse wheel do horizontal scroll when no vertical scroll is available.
Created attachment 121726 [details] [review] Patch for this issue With this patch nautilus compact view does horizontal scroll with the mouse wheel, I also tried the EOG image collection[1] and does horizontal scrolling with the mouse wheel... [1] In EOG menu, View->Image Collection to show it.
Comment on attachment 121726 [details] [review] Patch for this issue >Index: gtk/gtkscrolledwindow.c >=================================================================== >--- gtk/gtkscrolledwindow.c (revision 21651) >+++ gtk/gtkscrolledwindow.c (working copy) >@@ -1504,6 +1504,9 @@ gtk_scrolled_window_scroll_event (GtkWid > > if (event->direction == GDK_SCROLL_UP || event->direction == GDK_SCROLL_DOWN) > range = GTK_SCROLLED_WINDOW (widget)->vscrollbar; >+ if (!range || !GTK_WIDGET_VISIBLE (range)) { >+ range = GTK_SCROLLED_WINDOW (widget)->hscrollbar; >+ } > else > range = GTK_SCROLLED_WINDOW (widget)->hscrollbar; The "(!range)" part is wrong. Other than that I think this seems like intuitive behaviour.
Ok, I'll check on monday and resend the patch..
Created attachment 121864 [details] [review] New patch Ok, after testing it seems you are right so here is a new patch attached :)..
*** Bug 555571 has been marked as a duplicate of this bug. ***
if (event->direction == GDK_SCROLL_UP || event->direction == GDK_SCROLL_DOWN) range = GTK_SCROLLED_WINDOW (widget)->vscrollbar; + if (!GTK_WIDGET_VISIBLE (range)) { + range = GTK_SCROLLED_WINDOW (widget)->hscrollbar; + } else This is obviously incorrect (missing braces). Also, why not do this symmetrically, i.e. with horiz scroll on scrolled window with invisible horiz scrollbar, scroll vertically?
Created attachment 121891 [details] [review] [PATCH] Bug 558659 – In mousewheel event, do horizontal scroll when no vertical scroll is available in a gtkscrolledwindow Bug 132197 – Horizontal Scrolling Using Modifier Key and Scroll Wheel --- gtk/gtkscrolledwindow.c | 20 +++++++++++++------- 1 files changed, 13 insertions(+), 7 deletions(-)
(In reply to comment #7) > Created an attachment (id=121891) [edit] > [PATCH] Bug 558659 – In mousewheel event, do horizontal scroll when no > vertical scroll is available in a gtkscrolledwindow > > Bug 132197 – Horizontal Scrolling Using Modifier Key and Scroll Wheel > --- I've tested your patch and I like it very much, it fills both bug requirements with good defaults, thank you!
Having this functionality would certainly help users navigate around in scrolled windows. Think of the Rule of Least Surprise: if there is a scrollbar, the scrollwheel should work (that's the whole point of having a scroll wheel, right?), be it horizontally or vertically. This patch does just that.
*ping* Do we need to post to gtk list or ping someone to get this commited?
-1. In my opinion, this is counter-intuitive and feature bloat.
Thunderbird implements this in the mail list (at least on mac) and it sucks when you use a trackpad to scroll - you got to scroll down and right, otherwise scrolling left gets interpreted as scrolling up, so if you move fingers down and left (there is no horizontal scrollbar, so you just move fingers "down", without much trying to make it vertical only) then you get fancy effects of scrollbar jumping back and forth. Scrolling in random directions when content changes is also no fun (web browser, different pages, sometimes you have scrollbar(s), sometimes you don't, depending on the page). Interesting stories aside, it should be up to application. There is one application (or rather one type of widgets) where it's needed - file browser. Why change (i.e. break) everything for that one use case?
I don't have any opinion re how other apps should work, but please fix this in Nautilus and Compact View. I'm running Gnome 2.24 (Ubuntu 8.10) and this omission trips me up daily.
Taking in consideration the issues brought by comment 12, we could add a property to gtkscrolledwindow to activate this feature, it would be disable by default, and nautilus could enable it with eg. gtk_scrolled_window_set_orthogonal_scroll(window , TRUE); what do maintainers think, could this be included that way?
Fwiw, Nautilus has been changed to do this already, see Bug 571770 – Horizontal scroll on mouse wheel event.
(In reply to comment #15) > Fwiw, Nautilus has been changed to do this already, see Bug 571770 – > Horizontal scroll on mouse wheel event. > Oh, fine! , I wasn't aware of that bug, thank you.
*** Bug 550095 has been marked as a duplicate of this bug. ***
(In reply to John Boncek from comment #11) > -1. In my opinion, this is counter-intuitive and feature bloat. I agree. This is obsolete as Nautilus doesn't have a compact view anymore, and I don't like it as an idea for general use in GTK+. That said, it's not up to me, so let's see if any maintainer agrees...
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/304.