Re: [9fans] cooked mouse mode.

[rog@vitanuova.com]

paurea:
> > or, as charles points out, one might wish to pre-filter events, for
> > example to remove redundant mouse-moved events or perhaps to integrate
> > input from another device.
> 
> I would guess that kind of thing should be done with a filesystem wrapper like
> we are already doing.

i'd prefer to do it with a 10 line function (overhead almost zero)
than a 150 line separate filesystem implementation; especially as i might
wish to have my filtering affected by other stuff happing in my program.

nemo:
> But in any case, I dont' think it's good to let different apps use
> different kinds of mouse actions. That may lead to non-uniform UIs,
> which are not convenient for the user.

unfortunately modularity implies freedom and in this case the freedom
to build non-uniform UIs. i guess that's just the plan 9 way - it
hasn't got a standardised UI and probably never will.  no standard
"widget set".  no standard set of mouse actions.

it is, however, much simpler as a result.

the most you can do IMHO is to provide the tools to make it easy to
build uniform UIs (control(2) is an example) - to which end the new
mouse filtering is a nice contribution.  i will certainly use it the
next time i have to write a plan 9 gui app, assuming i can understand
the documentation...

speaking of which, structuring it as a separate module means that the
cooked events can become considerably more self explanatory, rather
than trying to squeeze everything into bitfields in a structure that
wasn't really designed for it.  for instance:

	struct Cookedmouse {
		int buttons;
		int event;		# MCLICK, MSELECT, MCHORD, MEND
		int clickcount;
		Point xy;
		ulong msec;
	};