GNOME Bugzilla – Bug 145244
tab scrolling: use mouse scrolling to switch between tabs
Last modified: 2018-05-02 14:02:03 UTC
Here is a patch against gtk+-2.4.0/gtk/gtknotebook.c to allow for tab scrolling. A bit of history: this is a feature I first found in a mozilla extension, MiniT, and in workspace switchers for XFce and Kde. Scrolling down moves to the right. --- gtknotebook.c.orig 2004-06-28 20:46:22.000000000 +0200 +++ gtknotebook.c 2004-06-30 15:08:30.000000000 +0200 @@ -159,6 +159,8 @@ GtkAllocation *allocation); static gint gtk_notebook_expose (GtkWidget *widget, GdkEventExpose *event); +static gboolean gtk_notebook_scroll (GtkWidget *widget, + GdkEventScroll *event); static gint gtk_notebook_button_press (GtkWidget *widget, GdkEventButton *event); static gint gtk_notebook_button_release (GtkWidget *widget, @@ -364,6 +366,7 @@ widget_class->size_request = gtk_notebook_size_request; widget_class->size_allocate = gtk_notebook_size_allocate; widget_class->expose_event = gtk_notebook_expose; + widget_class->scroll_event = gtk_notebook_scroll; widget_class->button_press_event = gtk_notebook_button_press; widget_class->button_release_event = gtk_notebook_button_release; widget_class->enter_notify_event = gtk_notebook_enter_notify; @@ -998,6 +1001,7 @@ * gtk_notebook_size_request * gtk_notebook_size_allocate * gtk_notebook_expose + * gtk_notebook_scroll * gtk_notebook_button_press * gtk_notebook_button_release * gtk_notebook_enter_notify @@ -1146,12 +1150,33 @@ attributes.wclass = GDK_INPUT_ONLY; attributes.event_mask = gtk_widget_get_events (widget); attributes.event_mask |= (GDK_BUTTON_PRESS_MASK | - GDK_BUTTON_RELEASE_MASK | GDK_KEY_PRESS_MASK); + GDK_BUTTON_RELEASE_MASK | GDK_KEY_PRESS_MASK | + GDK_SCROLL_MASK); attributes_mask = GDK_WA_X | GDK_WA_Y; @@ -1764,6 +1769,23 @@ return FALSE; } +static gboolean +gtk_notebook_scroll (GtkWidget *widget, + GdkEventScroll *event) +{ + GtkNotebook *notebook = GTK_NOTEBOOK (widget); + + switch (event->direction) + { + case GDK_SCROLL_RIGHT: + case GDK_SCROLL_DOWN: + gtk_notebook_next_page (notebook); + break; + case GDK_SCROLL_LEFT: + case GDK_SCROLL_UP: + gtk_notebook_prev_page (notebook); + break; + } + + return TRUE; +} + static gboolean gtk_notebook_button_press (GtkWidget *widget, GdkEventButton *event)
Nice idea. Committed to head.
Here is an update, meant to accept only events from the tab border. It just checks if the event originated from the notebook itself. --- gtknotebook.c.orig 2004-07-21 21:51:44.288952792 +0200 +++ gtknotebook.c 2004-07-23 20:58:53.395222848 +0200 @@ -1774,7 +1774,13 @@ GdkEventScroll *event) { GtkNotebook *notebook = GTK_NOTEBOOK (widget); - //Directions are an enum, not a bitmask. + + //We don't want events chained from the pages + gpointer originator; + gdk_window_get_user_data(event->window, &originator); + if(originator != (gpointer)widget) + return FALSE; + switch(event->direction) { case GDK_SCROLL_RIGHT: case GDK_SCROLL_DOWN:
Sorry, this patch doesn't solve the problem entirely: in epiphany, the tab border contains separate labels, which are other widgets. Since the patch refuses events originated from somewhere else than the notebook, epiphany would ignore scroll events on the label part of the tab border. Since the tab border and the notebook are the same widget and get the same events, the only solution would be to check the coordinates of the event.
This should be better, it checks if the event originator is within the current page's child. There is a slight imperfection, if the event originator is in the tabbar but is not a GtkWidget, the scroll event will be ignored. This is unlikely! --- gtknotebook.c.orig 2004-07-21 21:51:44.288952792 +0200 +++ gtknotebook.c 2004-07-24 14:25:50.682387280 +0200 @@ -1774,7 +1774,24 @@ GdkEventScroll *event) { GtkNotebook *notebook = GTK_NOTEBOOK (widget); - //Directions are an enum, not a bitmask. + + GtkWidget* child; + GtkWidget* originator; + + if(!notebook->cur_page) + return FALSE; + + child = notebook->cur_page->child; + gdk_window_get_user_data(event->window, (gpointer*)&originator); + + //Happens if the source is not a gtk widget + if(!originator) + return FALSE; + + if(gtk_widget_is_ancestor(originator, child)) + return FALSE; + //Now we know the event is from somewhere in the tabbar. + switch(event->direction) { case GDK_SCROLL_RIGHT: case GDK_SCROLL_DOWN:
If you add comments to a bug, you *must* reopen the bug. But don't reopen bugs unless the original bug reappeared. For a problem with the patch, open a new bug and Cc: the original bug reporter if relevant.
Reopening as a result of bug 630226.
Disabling this feature is really a major UI problem. Now, the only way to reach a tab that’s beyond the screen with the mouse is to click on the arrows on the border. As suggested in bug#630226, scrolling the wheel should make the tab bar move, but without actually switching.
(In reply to comment #7) > Disabling this feature is really a major UI problem. Now, the only way to reach > a tab that’s beyond the screen with the mouse is to click on the arrows on the > border. > > As suggested in bug#630226, scrolling the wheel should make the tab bar move, > but without actually switching. I discussed the issue on the #gnome-design channel, and the consensus there was that, while it's true that switching tabs on scroll can confuse unsuspecting users, Alt+scrollwheel is a good alternative for people who know how to use it.
Created attachment 189234 [details] [review] Re-add scrolling when Alt modifier is pressed Here you go. I hope everyone is happy with that one.
Created attachment 189245 [details] [review] Scroll when Alt modifier is pressed, from anywhere on the area Actually using Alt allows to do much, much better: switch tabs from anywhere on the notebook area. The patch also modifies GtkScrolledWindow so that the event is not intercepted to scroll in the window.
Thank you, thank you! Now just to get Google to copy that behavior in Chromium; I noticed that it is currently the only application on my desktop that does scrollwheel tab flipping. :)
After testing with more applications, I think other fixes will be needed: - in GTK+ itself, we need to ignore Alt+Scroll in GtkScrolledWindow but also in other widgets like GtkComboBox; - in VTE, I have prepared a patch that allows this to work in gnome-terminal; - in Webkit, it will need similar changes but the webkit internals are more complicated; Gustavo said it shouldn’t be too complicated.
Created attachment 195986 [details] [review] Scroll when Alt modifier is pressed Here’s an updated version that blocks alt+scroll from all other widgets in GTK+. However there’s a problem remaining: GtkNotebook doesn’t provide a GdkWindow for anything else than its tab bar. Before going further, I’d like to ask whether you are comfortable with adding a GdkWindow to receive events in the children’s area as well.
Created attachment 195987 [details] [review] VTE: ignore alt+scroll on the text area This is the complementary patch for VTE, which makes this behavior work in gnome-terminal.
(In reply to comment #14) > Created an attachment (id=195987) [details] [review] > VTE: ignore alt+scroll on the text area > > This is the complementary patch for VTE, which makes this behavior work in > gnome-terminal. Hmm, shouldn't this be filed separately in a bug against VTE then? Gtk+ developers, would you care to comment on Josselin's patch, please?
IMHO, latest ideas aren't that good - i.e. Alt+scroll might already be taken by window manager. Also, we'll be again at the point where there's no sane way of overriding this. On a related note: why was "scroll, but not switch" idea dropped (unless I'm misreading the patch) ?
I think there are too much of existing programs that are very tightly tied to interaction through wheel/6th and 7th button as a part of unix GUI tradition. Major examples are midori, epiphany, sonata, terminal, _gnumeric_, etc. Rewriting so much of code and rethinking interface from zero for minor benefit seems not to be a reasonable solution for me. Mousewheel use in tabs reduces mouseclick count for an operation. Using alt adds one additional button click. I propose to revert the removal and add a switch of some kind. >GtkNotebook allows you to switch notebook pages by using the scroll wheel on >the mouse. This seems kind of awkward and unintuitive, plus I've encountered a >couple mice that don't have a lot of resistance on the mouse wheel and the >wheel can continue spinning if you give it a little flick. >On a normal scrolled window, unintended scroll events only make the contents >move up or down a little further than you expected, but if you get unintended >scroll events on a notebook page it can be really surprising to a user, and >could really confuse them. Most of people have normal mices, with normal scroll wheels. I don't see this modification for a sake of small minority of users to be reasonable. This change degrades user experience, lowers application interactivity.
The existing feature also allowed you to scroll through tabs in an unfocused window without having to focus it. I use this a lot when I wanna read something without having to then go back to my focused window, and without having to mark it as 'always on top'. In some tabbed apps my tabs get very small and are small mouse targets. Tab scrolling decreases the precision required to switch. Everyone I know who's encountered tab scrolling (usually accidentally) immediately commented on what a good idea it is, and none were confused. I constantly miss it when I'm in Windows. Adding a modifier key seems like asking for trouble with conflicts. +1 for reverting the feature to how it was, or letting it be turned back on in dconf.
I think that using "Alt" key to enable switch-scrolling is a bad idea, because this kind of key shortcuts shall be reserved for application (especially if the scope is outstretched to the whole child widget) or desktop environments. Furthermore, a simple scrolling is very convenient because it's easy to do. If we have to press an extra key to switch a tab, this feature will lose nearly all its benefits...
(In reply to comment #19) > I think that using "Alt" key to enable switch-scrolling is a bad idea, because > this kind of key shortcuts shall be reserved for application (especially if the > scope is outstretched to the whole child widget) or desktop environments. Alt+scroll isn’t use in any of the applications I have checked that use GtkNotebook. > Furthermore, a simple scrolling is very convenient because it's easy to do. If > we have to press an extra key to switch a tab, this feature will lose nearly > all its benefits... Have only to press an extra key instead of moving the cursor to the tabs bar is much easier.
(In reply to comment #20) > (In reply to comment #19) > > I think that using "Alt" key to enable switch-scrolling is a bad idea, because > > this kind of key shortcuts shall be reserved for application (especially if the > > scope is outstretched to the whole child widget) or desktop environments. > > Alt+scroll isn’t use in any of the applications I have checked that use > GtkNotebook. > Ah, but were different window managers among them ? Cause Alt+scroll there gets often used for things like i.e. desktop switching and as a window manager got priority the in key grab over an app, app will never receive it in such case.
Maybe it could be possible to make these 2 possibilities coexist. I mean, to let the simple scroll work on the tab bar (perhaps with an option in gsettings to enable this), and to introduce the extended scroll with "Alt" on the child widget.
(In reply to comment #22) > Maybe it could be possible to make these 2 possibilities coexist. > I mean, to let the simple scroll work on the tab bar (perhaps with an option in > gsettings to enable this), and to introduce the extended scroll with "Alt" on > the child widget. Yes, that would be wonderful. When can we expect a patch?
*** Bug 661950 has been marked as a duplicate of this bug. ***
The patch (attachment #195986 [details]) breaks notebooks that are only used for internal purposes. Steps to reproduce in Evolution: 1. Open Evolution 2. Switch from E-Mail to Calendar view 3. Switch back to E-Mail view 4. Alt+Scroll on the Folder list or E-Mail list Empathy: 1. Do a search with no matches once (not neccessary, but makes it possible to recover without restart) 2. Alt+Scroll on the Contact list 3. Type something to recover again
Ping, sadly tab scrolling through gtk notebook isn't working in GNOME 3.6 Who has a way to enable this please?
I really need it back, I use it a lot and for example in qt it's on by default. Please make an option to restore the previous behaviour
What's the state on this? if this was working in the past, does anybody know what commit cause it to be broken? Not being able to scroll tabs with mousewheel makes using gedit a pain when hacking on code because you usually end up with a lot of source files opened.
It wasn't broken, it was removed. The feature was considered to do more harm than good in terms of user interaction.
(In reply to comment #28) > What's the state on this? if this was working in the past, does anybody know > what commit cause it to be broken? https://git.gnome.org/browse/gtk+/commit/gtk/gtknotebook.c?id=ad48f4d52bbac6139dd829fcc421ad16441f34d2 You may want to patch your local gtk3 builds like I do for example. (In reply to comment #29) > It wasn't broken, it was removed. The feature was considered to do more harm > than good in terms of user interaction. Are there any plans for a replacement for feature parity? E.g. the Alt+wheel proposal from comment 8 looks like a good alternative. Noticing this bugreport is still in a NEW state...
(In reply to comment #30) > (In reply to comment #29) > > It wasn't broken, it was removed. The feature was considered to do more harm > > than good in terms of user interaction. > > Are there any plans for a replacement for feature parity? E.g. the Alt+wheel > proposal from comment 8 looks like a good alternative. Noticing this bugreport > is still in a NEW state... if you notice, there were issues with that patch. if somebody wants to add support for Alt+Scroll while checking for regressions, then we can review the patch.
(In reply to comment #29) > It wasn't broken, it was removed. The feature was considered to do more harm > than good in terms of user interaction. Thanks to you and others who provided info about the state of this issue!, by the way, after reading this bug and bug 630226, the functionality I was missing is not old "scrollwheel-switch-to-tabs" but just a quickly way reach tabs that are offscreen, which is by scrolling tabs as you do in firefox. In the original bug where Cody Russell removed this feature he also agreed on this needed feature, from https://bugzilla.gnome.org/show_bug.cgi?id=630226#c5 : > Except timj brought up an important point in irc, which is what happens when > the area occupied by the tabs exceeds the visible area in the window and some > are offscreen. My feeling is that we should do what Firefox does in this case, > and let the mouse wheel scroll the tab area without actually selecting another > tab. > So I'll try to solve this in a separate patch. It seems that patch was never done. So, do you agree on the benefits of such a patch? Do you think could be accepted? It would improve usability when having lots of offscreen tabs, which is a common scenario when browsing internet with epiphany or using gedit to hack on code. The alternative solution would be auto-shrinked tabs as chrome does, but the firefox tab scrolling is good enough for us in my opinion.
*** Bug 711398 has been marked as a duplicate of this bug. ***
*** Bug 738266 has been marked as a duplicate of this bug. ***
$50 bounty added here: https://www.bountysource.com/issues/3554529-tab-scrolling-use-mouse-scrolling-to-switch-between-tabs
Created attachment 292094 [details] [review] GtkNotebook: Add scroll event I don't remember where this patch come from, but I'm using it for more than year (I build GTK+ with this patch), it works very well. (the code it not mine, I don't remember who write it, I just rebase it every time.)
Oops, it probably come from here (I take it from AUR, but it come to AUR from here, probably). Anyway, it rebae from GTK+ from git master, and it work pretty well.
*** Bug 741698 has been marked as a duplicate of this bug. ***
*** Bug 750374 has been marked as a duplicate of this bug. ***
What's the status of this? Is there any reason to not make tab-scrolling-with-mousewheel an option that is disabled by default? That way, no confusion for new users, but those of us who find it super useful can enable it.
(In reply to alexrichert from comment #40) > What's the status of this? The same as comment #31: the existing patch (see comment #36) has issues. If somebody wants fix those issues and implement Alt + scroll wheel, then we can review the patch. As far as I'm concerned, this "feature" should only be applied if the scrolling is either discrete (i.e. old X11 core events for scroll wheels) or if the input device is *not* a touchscreen/trackpad; it should also only be masked with a modifier, like Alt. Those are my prerequisites. > Is there any reason to not make > tab-scrolling-with-mousewheel an option that is disabled by default? An option disabled by default means that nobody is going to test it for regressions. > That way, no confusion for new users, but those of us who find it super useful > can enable it. That's not how stuff usually works.
Default-off optional features are the worst... you're basically adding guaranteed future regressions into the code base. For a marginal benefit to the few who discover the magic option.
-- 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/234.