Re: [Usability] GtkNotebook scrolling

[Shaun McCance <shaunm gnome org>]

On Thu, 2010-03-11 at 12:00 -0600, Cody Russell wrote:
> I brought this up on desktop-devel-list and gtk-devel-list hoping to get
> some usability feedback, but the responses have been more of the "hey, I
> use that sometimes!" type of response which isn't what I want.  But then
> Cosimo mentioned that we have a real usability list, and so here I am!
> 
> So, I stumbled upon this feature we have where you can use mouse-wheel
> scrolling on GtkNotebook pages to change to a different page.  It wasn't
> the most pleasant experience for me since I did it on accident and was
> briefly quite confused.  I'm not a usability expert by any stretch of
> the imagination, but my gut feeling is that if something confuses me for
> even a moment then it might be a usability flaw for average users.
> 
> I mentioned the issue to Matthias Clasen on irc and he seemed to agree
> with me.  But I want to get some feedback from people: are there really
> good use cases for this?  Is it something that should be explicitly
> enabled or disabled in certain places?  Does it make more sense if you
> have tons of small notebook tabs?  Is it something that could be
> configured somewhere?  Or maybe I should just leave it as-is, or maybe
> rip it out entirely?

Responding to various things people have said so far in
this thread, so I'm just doing it at the top.

>From the people who say they use this features (including
me), it seems to be most commonly used when there are more
tabs than fit on the screen.

So Firefox doesn't switch tabs with the scroll wheel.  It
also doesn't switch tabs when you click the arrow buttons
you get when there are too many tabs.  Instead, in both
cases, it just scrolls the tabs left and right.  This is,
I think, still quite useful, and it doesn't suffer from
the jarring "what just happened?" reaction of what we do
right now.  Maybe we should switch to that behavior.

Re: comboboxes that also use the scroll wheel, this has
actually bit me multiple times.  And I actually like the
feature on its own.  But when a combobox is in a scrolled
window, disaster is inevitable.  It would be nice if we
could disable that feature only when the widget is inside
a scrolled window.

Unfortunately, AFAIK, this involves special-casing widgets
to check their parents (and parents' parents, etc).  GTK+
events go strictly inner-out.  I've run into snags because
of this in the past, with drag-and-drop code.  I seem to
recall Emmanuele Bassi saying Clutter uses a two-pass
event propagation system: inner-out-and-back-in.  If we
had this, and if scroll events were handled on the second
pass, this problem would be licked.

(And, I suppose, that kind of discussion belongs back on
gtk-devel-list.)

--
Shaun