Created attachment 170734 [details] [review]
Proposed patch

Just for reference, this feature was originally added in bug 145244.

This was approved in the GTK+ meeting in irc.  Committed to git master.


commit ad48f4d52bbac6139dd829fcc421ad16441f34d2
Author: Cody Russell <bratsche@gnome.org>
Date:   Tue Sep 21 16:18:22 2010 -0500

    Remove mouse scrolling from GtkNotebook tabs.  Bug #630226.

Has the opinion of UI design and behaviour experts been asked, etc?
I regularly use this scrolling feature in various notebooks (e.g, preference panes) to much quicker switch to a different tab - instead of having to move the mouse pointer to the desired tab, I just hover the tabs area at a closest position and scroll the mousewheel appropriate amount of steps. My mice have strong physical mousewheel interaction feedback though, not those smooth scrolling types.
I also use this in the taskbar and pager often enough, but I'd guess that's custom code for the taskbar (and obviously custom for the pager).

The closest thing that I have to UI design and behavior experts at my disposal is the design team at Canonical, and when I asked them about this change they agreed very strongly with it.  Otherwise, I've only received positive feedback from other users and developers.

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.

I would expect other users coming out of the woodworks once this deploys to them after March with GNOME3 though, I just happened to read meeting minutes. It is removal of a feature, afterall, and I keep hearing about how GNOME is all about removal of features that people use.
For consistencies sake, are we going to remove all mousewheel previous/next behaviour then, as found also in the taskbar, pager and other places? (and what I also find a very useful feature, alongside the notebook scrollwheel one)

I'm also, like Mart, a heavy user of that feature that I find very helpful for speed. I also use scrolling for combobox switching often -- when I know the options -- and globally everywhere it's possible.
The main reason I see to use this for notebook tab switching is probably the fact that you don't need to have the mouse over the exact tab you want to switch to it -- and honestly I generally want to go do a tab close to the current one. So I personally use it heavily in gnome-terminal, geany (a text editor), and -- yes, no kidding -- Firefox. For Firefox I use a plugin to get the feature (TabMixPlus) which helps me a lot.

I don't think that the default Firefox's behavior (scroll only the tabs "headers", no switching) is useful. If you have enough tabs to need scrolling, the drop-down menu to select tabs is far more useful: it provides overview of your tabs, not only a few of them.
Same if the tab header is too wide: the tab header scrolling don't really help since you'll only be able to see a few of your tabs at once, so it will be a pain for you to find the actual tab you want. And when you've found it, you will need to finally click on it.
So IMO it's counterproductive.

I agree that it perhaps *can* be unintuitive for new users, but I think it's not something complicated to learn, and it's *really* useful for anyone who use it (I don't seem to be alone). Actually, it was something I was searching for in Qt4 apps, and AFAICT it is back in recent versions.

I'm not sure for the mouse problem from the report, but I'd think that it should be fixed in the mouse side if possible. If you don't control your input devices, what can you do?
But I'm not sure it is really possible to fix the sensibility of a mousewheel? So perhaps that's a possible good reason.

I would really want the functionality to stay in GTK. If there are really good reasons fro some not to want this, I'd suggest a GtkSetting (that gnome's UI configurator would show), controlling mouse wheel support for Notebooks, ComboBox and other stuff (for consistency). On or off by default, I don't really care.


--

Apart from this, I'm not always sure about what some "usability guys" says. One thing that immediately comes to my mind is the removal of icons in menus under GNOME. Yes, the UI is more unified in a certain way, but I saw many people (including me) having more trouble to find the right item it those icon-less menus. People was used to use the icons as reference points in the menu, now they have only text. Icons are generally easier to recognize than plain text.

Another thing that I see too often -- and it is the case for this feature we talk about -- is removal of functionality because "it is useless" or "it's too complicated", regardless the fact that the functionality was introduced, and that many people actually find it useful.
I'd say simplification is good, but sometime it needs to really check whether the functionality loss values the simplicity gain.

I like lots of job done by the usability guys, but sometime I think they go too fast or only from one point of view -- probably their own, which is not that bad. So please, don't fire it as "the actual truth", only a (perhaps clever) point of view :)

Mousewheel tab scrolling has worked absolutely brilliant for years. Something that works should not just be removed without warning or way to revert to the known behavior. If the problem is that the mouse wheel can be too sensitive leading to unexpected tab switches, IMHO the solution is to have a treshold by default, much like drag-and-drop. Please consider this. Thanks!

I agree with Mart, Colomban and Reinout. This feature may be disappointing for new users, but it may be really useful when you know how to use it. This may be a good idea to turn it off by default, but please keep a GtkSetting to change this behavior, just like button icons, nautilus spatial mode, etc.

New users would be happy, power-users would be happy.

The patch removes less than 50 lines of code, keeping them won't increase that much the complexity of GTK+ :).

Thank you for your work…

Please do not remove this feature - please at least provide a setting.

Please do not forget power users. Please do not remove useful features existing users love and use every day. Changing defaults is OK, but don't kill features.

The end result of this change is that some applications are just implementing the functionality themselves now that it's been removed from Gtk+:
http://git.gnome.org/browse/gnome-terminal/commit/?id=e2299ee2451167ad41b35705b4fbd577aebd0c39
Which unfortunately results in inconsistant user interface... Tab scrolling works in some programs but not others.

Applications re-implementing this feature (as Calvin posted about gnome-terminal in #c11) is a very bad idea - the code is not that trivial to implement and so may increase the bugginess of Gnome applications. It also adds work and hassle for application maintainers if they decide to implement this feature.

Could any GTK devs who really feel there shouldn't be an off-by-default global setting for this please explain why that would be such a bad thing in comparison to applications implementing this themselves?

*** Bug 640292 has been marked as a duplicate of this bug. ***

Please do not remove this feature +1.

(In reply to comment #8)
> Mousewheel tab scrolling has worked absolutely brilliant for years. Something
> that works should not just be removed without warning or way to revert to the
> known behavior. If the problem is that the mouse wheel can be too sensitive
> leading to unexpected tab switches, IMHO the solution is to have a treshold by
> default, much like drag-and-drop. Please consider this. Thanks!

This feature is one of the reasons I have switched over to GNOME. I can see at least two strong arguments in favor of re-enabling this feature:

- it enables the user to switch tabs by looking at their _content_, which is clearly easier to recognize (especially in web browsers) than their labels.

- in enables the user to switch tabs without having to correctly position the mouse over the tab they want to switch to, which is (a) less distracting, because I don't have to move my eyes from the tab contents to the tab label, (b) easier, and as a consequence (c) faster.

I think that this feature should have not been removed in the first place. The rationale would be: "if users don't complain about it, either they find it useful or they really don't mind".

Bugzilla basically samples user satisfaction, and the fact that this feature is not mentioned anywhere (AFAICT) is quite strong support for my argument.

Furthermore, I don't really get why designers (or developers) would want to completely remove a (perhaps niche) feature, versus just disabling it by default. The latter option would be preferable.

I'd really like the hear the opinions of the UX people here.

Thanks.

Me too: Please do not remove this feature +1. I use it all the time, in lots of different applications (gnome-terminal, meld, gedit, browser...).

Please do not remove this feature +1 from me too.

Change the default if you want, but please do _not_ remove this feature that I use every day.

I started using Gnome 7 months ago, coming from Windows, and didn't find this feature confusing at all. Quite the opposite: I fell in love for it because it was a great improvement in my user experience, for the "intuitiveness" and "naturality" it brought to my desktop.

Now, whenever I work on a Windows computer, I find myself scrolling tabs (in Google Chrome, for example) and finding it frustating it does nothing. It feels like the computer is "dumb", it doesn't understant my way of thinking.

I undestand many users won't use this feature, but is is an obstacle just because you don't know about it?

Maybe the reason for new users to find it an unexpected behavior would be the fact that there is no such behaviour in Windows and it was with Windows they learnt how to work with a computer. But is that a reason no to have this feature just because users don't know about it because Windows doesn't have it?

"Design a self-teaching interface for beginners, and an efficient interface for advanced users, but optimize for intermediates"

Honestly, this "feature" has already been removed in gtk+ 3 and hasn't been touched in gtk+ 2.

Personally, I'd like to at least have an option to disable "switch on scroll" behavior in gtk+ 2 too, as I never liked it - I prefer the way TabMix Plus does it in Firefox (that way, I can use scrolling, but page is switched only if I choose to - that's a big plus if you want "upon tab close switch to the last active tab" to be usable).

After reading my previous comment, I guess I was not considerate. I'm sorry, please ignore it.

Instead, "please do not remove this feature +1"

Removing this feature is non-sense. It's a HUGE user experience improvement.
It made me save a lot of time.

Just re-add it already.

Is anyone here against this solution:
- Keep the scrolling feature
- Disable it by default with a global setting
- When the feature is disabled, scrolling behaves as described in comment 5

Some people would prefer this feature enabled by default. But a checkbox in dconf-editor is a really easy way to enable it. That should be OK for them.

Some people would prefer this feature removed. But the behavior by default is the same as if the feature was removed. That should be OK for them.

A lot of people here are against removing this feature, sometimes with explicit arguments (comment 15). There are also arguments in favor of removing this feature (bug description, comment 20). All these arguments are compatible with the solution described here.

If there are reasons explaining why removing the feature is better than disabling it by default, everyone would be happy to discuss them and find a better compromise. But letting this bug marked as "resolved fixed" is a little bit frustrating, as it gives the impression that the choice has been made and will never ever change again.

(In reply to comment #23)
> If there are reasons explaining why removing the feature is better than
> disabling it by default, everyone would be happy to discuss them and find a
> better compromise. But letting this bug marked as "resolved fixed" is a little
> bit frustrating, as it gives the impression that the choice has been made and
> will never ever change again.
+1
However, it unfortunately is likely to be the case since (AFAICT) Bugzilla doesn't send updates to the CC list when the bug is resolved :,(

(In reply to comment #20)
> Personally, I'd like to at least have an option to disable "switch on scroll"
> behavior in gtk+ 2 too, as I never liked it - I prefer the way TabMix Plus does
> it in Firefox (that way, I can use scrolling, but page is switched only if I
> choose to - that's a big plus if you want "upon tab close switch to the last
> active tab" to be usable).
Not sure I understand... I personally use TabMixPlus actually to GET this feature. But TMP has a lot of feature, maybe you have it configured otherwise. Can you describe the behavior you like a little more in depth?

Sure:
extensions.tabmix.focusTab;4
extensions.tabmix.tabBarMaxRow;2
extensions.tabmix.tabBarMode;2
extensions.tabmix.version;0.3.8.4

(I think those are the relevant - yes, IIRC, TabMixPlus is required for this,
as by default, firefox handles it badly)

People, please. This is a bug report, not a help forum for Firefox extensions. Only comment if you have something to say that's relevant to the bug. Thanks!

(In reply to comment #26)
> People, please. This is a bug report, not a help forum for Firefox extensions.
> Only comment if you have something to say that's relevant to the bug. Thanks!

Well, I'd say it stopped being a bug report the moment it was RESOLVED FIXED.

Any later comments were just complaints about a done deal.

Should this have been discussed a bit more  before unimplementing or on a wider forum, than the two mailing lists it was discussed on (usability and one other) ?

Probably yes.

Personally I would like this misfeature gone in gtk+ 2 too or at least programmatically disableable - right now there doesn't seem to be a way to do it without breaking whole tab switching.

But usually whining on bugzillas doesn't get much done in cases like this.

(In reply to comment #25)
> Sure:
> extensions.tabmix.focusTab;4
> extensions.tabmix.tabBarMaxRow;2
> extensions.tabmix.tabBarMode;2
> extensions.tabmix.version;0.3.8.4
> 
> (I think those are the relevant - yes, IIRC, TabMixPlus is required for this,
> as by default, firefox handles it badly)
I would probably have been better to describe the behavior rather than dropping the configuration of TMP since not everybody has TMP and it need at least to reconfigure it... anyway, I tested it and don't feel it neither comfortable nor intuitive.

What I get is:
1) 2 rows of tabs
2) when scrolling the view to show overflown tabs, the tabs moves around (e.g. the current tab was on the 1st row but moves to the 2nd one... odd)
3) the current tab may not be visible (though, this is inherent to view-only scrolling, that's not necessarily an issue)

Though of course it's personal taste, I doubt that points 1 and 2 are really good defaults. 1 is uncommon, and 2 is IMHO really counter intuitive as tabs may change place in an "unexpected" way: who would think that the tab would move vertically when clicking on a button with an horizontal arrow on it? Or when using mouse wheel on an horizontal widget?


I think that having a configuration option is probably the best way, but I also thing that only 2 "modes" are worth considering:

1) Scrolling (using the notebook's buttons or the mouse wheel) work as before this "bug" get "fixed": tab changes to the one beside the current;
2) Scrolling (using the notebook's buttons or the mouse wheel) only scrolls the "view", the current tab does not change.

Either being the default, I personally think a setting is easy to change, moreover it it appears in GNOME's UI configurator.

If it is the mouse wheel support that bothers some users, maybe a simple option to enable or disable it is good enough?

Please make this configurable with a dconf setting

>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.

There are a lot of applications that are tightly tied to interaction through mousewheel. Just for example : midori, epiphany, sonata, terminal, _gnumeric_, etc. Mousewheel use in tabs reduces mouseclick count for an operation.

Perhaps we should file a new bug requesting a global setting to restore this behaviour, off by default. It seems all our comments have been ignored, perhaps because this is marked resolved/fixed.

(In reply to comment #32)
> Perhaps we should file a new bug requesting a global setting to restore this
> behaviour, off by default. It seems all our comments have been ignored, perhaps
> because this is marked resolved/fixed.

A new bug won't be necessary as I have reopened bug 145244.

Maybe I've missed the inside info on how to re-enable this feature myself. Does someone have a Dconf workaround, or other? Yes I can agree this could be off by default, but it doesn't make sense to dumb down the entire desktop for users who still use this!