Created attachment 27869 [details] [review]
Proposed patch against HEAD. Works like a charm. Nifty and handy :).

Created attachment 27871 [details] [review]
New patch.

The former patch didn't check whether the event didn't actually come from the
frame client area. This one does so.

I don't think this is a very good idea; one would expect the scroll wheel to
scroll, not make the window vanish. I think there may be an old bug with more
discussion.

Chris: I believe Havoc's comment may have come from your vague description.  He
may not have understood that you meant to shade on mouse roll *only when the
mouse is over the window frame*.

If I'm wrong, then Havoc:  What would one expect the scroll wheel to scroll when
the mouse is over the window frame?  (Personally, I hate shading altogether--but
I never scroll the mouse wheel when the mouse is over the window frame either.)

Well, I guess a larger issue is that I think mouse scroll should be based on
click to focus, not mouse focus as it is now. So then you would not have to be
in the scrollable widget to scroll it, you might be accidentally on the titlebar
for example.

Ah, I see...  So, close as NOTABUG?

Well, I'm willing to leave the bug open if people want to discuss, I'm just
saying it doesn't seem like a good idea to me. Though I guess people can discuss
just as well with it closed. ;-)

There was some old mailing list thread about scroll wheel and click/point to
focus I think, I don't remember the conclusion.

Seems like enough time has elapsed for discussion.

Let's give usability geeks another chance :). I've contacted usability@gnome.org.

regs,
 Chris

Okay, I have a few points here:

Did I read the patch correctly in that it just grabs the scrollwheel event with
no modifyer keys? In such a case, it will cause strange behaviour and odd
usability cases from people who simply are clumsy, or sit and drag the
scrollwheel pretty much like others play with their rings and pens ;)

To move a window, we currently use click+drag, which is a consious thing, its
hard to "miss" when doing that.

To move "any" window, you alt+click and drag.

So, either make it a modifier key... or perhaps make the scrollwheel do some
other action,  like move the window to a different workspace ;-)

however,I'm fairly biased against the wheel-only since its not obvious, and
where the window goes isn't obvious at all. 

DmD: I think it's "not obvious" only in the context of other apps' use of the
mouse wheel.  

Mapping the wheel to shade/unshade seems very obvious to me when I think about
windows as concrete objects and not abstractions.  In this sense the action
becomes "tactile."

The consensus seems to be that while some people might like this feature, it
will seriously degrade the usuability of the desktop.  Seems to me like that's a
pretty powerful argument against including it.

I'd vote against, it's very unobvious for users unfamiliar with shading (even
doubleclick to shade most often confuses them first few times, but at least they
usually notice they doubleclicked). Wheel is very subtle and prone to
subconscious movement, plus there are mice (like mine) that sometimes just fire
up scroll event by themselves.

And regarding #5: NO! Don't even try making wheel follow focus. Win32 currently
does that, and it's completely awful behavior, forcing me to track (often very
non-obvious) focus. Wheel is placed _on the mouse_ for a reason - if I wanted
focus dependant scrolling, I'd use PgUp/PgDn.

Thanks for your comments.

(Just for reference--duplicate of bug 91338)

Since the question of what to do given various mouse events on titlebars is handled by an enum in bug 408898, we could always put this in in a similar way now-- as well as "double-click on titlebar", "right-click on titlebar" and friends, we'd have "scroll-wheel-up on titlebar"-- and then set the action to "none" by default. That would avoid astonishing average users who did it by mistake, and it's a better solution than having a one-off boolean pref to turn it on, which was discussed earlier in this bug. And if we're going to allow double-click actions, and right-click and middle-click actions, this seems to follow naturally on.