Re: Could we have mouse-wheel support before the feature freeze ?

[Owen Taylor <otaylor redhat com>]

Guillaume Laurent <glaurent@worldnet.fr> writes:

> Please ? There already are two patches lying around, and it's really
> not something destabilizing or hard to test. Moreover, it's really a
> big ergonomic plus which Gnome would greatly benefit from.

One reason I was a bit hesitant to add the previous patches,
is because they seemed a bit like hacks, they did quite
different things, and I wasn't sure either was really doing
the right thing.

I haven't fooled around with the scroll-wheel in windows,
and I haven't used one myself, but it seems to me that
the correct behavior is:

 - If the mouse is over a scrollbar (horizontal as well
   as vertical?) scroll that.

 - Otherwise, if the mouse is anywhere inside a scrollable
   widget, scroll that, by some distance determined
   by the adjustment. (Is adjustment->page_increment
   too much. Is adjustment->step_increment too little?
   How about the geometric mean? 
   (sqrt(page*step), not sure if I'm joking about that)

One solution would be to modify the event handlers in
GtkCList, GtkCTree, GtkLayout, GtkViewport, and GtkText
(any others?) to all interpret button 4-5 correctly.

I think a better solution might be to add BUTTON_PRESS
event to GtkWindows' event mask, then in the
button_press_event() handler, hunt down the widget tree
using the coordinates in the event until you find a
ScrolledWindow and scroll that.

(It would be even nicer to hunt until we find a
 scrollable widget, but the "set_scroll_adjustments" 
 that was just added has no "get_scroll_adjustment"
 counterpart)

That would be easy if GTK+ had a widget-level
XTranslateCoordinates equivalent. If someone wants to
work on the above, I can whip that up in a few minutes
from code I wrote in gtkdnd.c.

Regards,
                                        Owen