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

[Paul Barton-Davis <pbd op net>]

In message <199903021106.LAA25722@diamond.tao.co.uk>you write:
>[...]
>>It almost certainly has to be done in the X server. I have a trackman
>>marble fx. It doesn't generate any particularly different messages
>>when button 4 is pressed than when its not, so the server needs to
>>keep the button state, and translate the ball motion events into
>>something else when it knows that the button is pressed. This is not
>>particularly hard, but is more appropriate for someone in the XFree86
>>group to do, since it might have some subtle implications for other
>>aspects of pointer handling.
>[...]
>
>The problem is, how is the X server supposed to know which window to scroll? 
>It can't tell the difference between a widget window or a scrolled window or 
>an application window or anything else. It doesn't know about windows which 
>don't actually scroll, the contents are just redrawn at a different place 
>according to where the scrollbar is. In Windows, the driver can tell all this;
> 
>in X, it can't.
>
>It would have to be implemented in the toolkit rather than the server; and it 
>wouldn't be terribly hard. If a scrollable widget detects a 4-click, it grabs 
>the mouse pointer, and turns all mouse motion events into window scroll 
>events, warping the mouse pointer back to its original position after each 
>event. When it receives another 4-click it releases the pointer and goes back 
>to normal.

No, no, no, no, no.

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.

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 :)

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

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.

--p