Re: [gtk-list] Re: wheel support, was: Re: Plans for 1.3/1.4

[Ben Darnell <bgdarnel unity ncsu edu>]

Paul Barton-Davis wrote:

>
> This is not how X should work at all. It implies building h/w specific
> knowledge into a toolkit, which is, IMHO, utterly, utterly wrong. It
> also implies building user interface policy into the toolkit. Consider
> the case of a 4-button non-trackball mouse. What will your toolkit do
> then when the user tries this, and gets a totally different response
> than expected ? Unless you intend to define the use of the mouse as
> "button-4 plus motion = 3D scroll". I suppose this is a rational
> decision, but its people with wheel mice want "button-4 is scroll up,
> button-5 is scroll down" or something similar, and this would be very
> confusing.
>

I don't think that anyone is suggesting that 4+motion should always be mapped to
scrolling.  This should obviously be user-configurable, as should the 4/5
scrolling for wheels.  Configurations could be something like "click4=scroll-up;
click5=scroll-down" for wheel mice, or "drag4=scroll" for people who want this
functionality.

>
> The server's job is to abstract the h/w specifics into a later that
> can be used without h/w knowledge. This means X events. If you press
> button 4 and move the wheel, its the server that should be sending you
> events, perhaps an MotionEvent with a modifier (except that
> MotionEvents don't have modifiers :)

But the server does abstract the signals sent by the hardware into a generic form
- buttons and motion in two axes.  I don't see how the toolkit using button 4 for
scrolling is any different than using button 3 for context menus.  X was designed
to specify mechanism, not policy.  The X server generally leaves interpretation of
hardware events to the application.

That said, I agree that it would be a cleaner design to let the X server handle
this and send scrolling events to applications.  (If nothing else, it means only
one config file to work with).  However, there are no X events that relate to
scrolling (AFAIK).  Is it possible to add a modifier to MotionEvent?  Also, if
this was done, the server would have to be able to map buttons 4 and 5 to vertical
MotionEvents for people who use wheel mice.

>
>              switch (ev->type) {
>              case MotionEvent:
>                        if (ev->modifier & MotionModifier1) {
>                                do_scroll();
>                        } else {
>                                do_motion ();
>                        }
>              break;
>

The if statement here could just as easily be "if (is_button_down(scroll_button))
{", which would not require resorting to non-standard X extensions.

>
> this way, apps and toolkits which don't know about MotionModifier1
> will be left untouched, and those that do will handle it in a h/w
> independent fashion that allows the user to specify what kind of input
> context causes MotionModifier1 to be set.

This is true whether the scrolling support is done in the X server or the
toolkit.  The advantage of doing it at the X server level is that 4-drag and
4/5-click scrolling can be handled by the toolkit in the same way, and the user
only has to configure this in one place.  The advantage of doing it entirely in
the toolkit is that it will work even on an unmodified X server, and that apps
that don't understand scrolling will still get the 4 and 5 mouse events as normal
(using a motion modifier would hide these events from the application).

Ben Darnell