[9fans] cooked mouse mode.

[9fans] cooked mouse mode.

[Gorka Guardiola]

We have written and submitted a cooked-mouse mode patch. 
It means that while using mouse(2), setmousemode
can be called in order to stop getting raw mouse events and start getting them
cooked so the state machine for proccessing single clicks, double clicks, slides, 
chords and so on (which is difficult to get right) isn't rewritten
for every application and has a clear boundary. The state machine is implemented 
as an interpreter for a minilanguage with the program hardcoded in it, but all
that is isolated from the user of the library. A typical use for this would be:

1) call setmousemode

setmousemode(mousectl, MCOOKED);

2) receive events from the channel already processed:
	for (;;) {
		switch(alt(alts)) {
			case Akeyboard:
				if(r==DELETEKEY)
					threadexitsall(nil);
			break;	
			case Areshape:
				resized(1);
			break;
			case Amouse:
				if (button==(MCLICK|MEND|2)){
					//single click with the 2 button
   				}

				if (button==(MCLICK||MDOUBLE|MEND|1)) {
					//double click with the 1 button
				}
				if ((button&(MFLAGS|7)) == (MEND|MCHORD|MCLICK|4|1)){
					if (MCHORDB(m->buttons,0) == 1){
						//chord with buttons 1 and 3, the first being 1.
					}
				}
		}
	}

We are finding it very useful in Plan B. Oppinions, ideas, suggestions?.
The genealogy of this is funny:

squeak (language for the mouse) ->aleph->libthread->cooked mouse


										G.

Re: [9fans] cooked mouse mode.

[rog]

> We have written and submitted a cooked-mouse mode patch. 
[...]
> A typical use for this would be:
> 
> 1) call setmousemode
> 
> setmousemode(mousectl, MCOOKED);

is there a particular reason why this has to be a patch in mouse(2)?
could it not be implemented simply by a simple thread that receives
events from the usual mouse channel, translates to "cooked" mouse messages
and sends these down another channel, to be received by the application?

say:
	Channel *cookedmouse(Channel *);

that way none of the existing code needs to change; it seems to me
that this is the kind of thing that the channel idiom is tailor-made
for.

i'm probably missing something.

Re: [9fans] cooked mouse mode.

[Gorka Guardiola Múzquiz]

We wanted to make explicit to choose between cooked events or raw events, no 
to expose the two interfaces at the same time, which may get applications
into a kludge. You must choose cooked or raw, not being able to see both at 
the same time.

We also put it there because this is related with the buttons of the mouse 
and all that stuff in mouse.h, so
putting the flags and things in mouse.h seems a good place for it. Yet 
another is that we tried to make it as much as possible "backwards 
compatible",
so it could be used (some issues which are referred in the manual appart), 
from programs already written without many modifications (calling 
setmousemode). Anyway, the code
modified is very little (in mouse.c the multiplexation and in mouse.h the 
flags and a macro). The main part of the code is in cook.c another file
completely separated which does exactly what you say, if you are in cooked 
mode, the events go to a thread which cooks them and writes them back to the 
output chan.

----- Original Message ----- 
From: <rog@vitanuova.com>
To: <9fans@cse.psu.edu>
Sent: Thursday, January 13, 2005 8:59 PM
Subject: Re: [9fans] cooked mouse mode.


>
> is there a particular reason why this has to be a patch in mouse(2)?
> could it not be implemented simply by a simple thread that receives
> events from the usual mouse channel, translates to "cooked" mouse messages
> and sends these down another channel, to be received by the application?
>
> say:
> Channel *cookedmouse(Channel *);
>
> that way none of the existing code needs to change; it seems to me
> that this is the kind of thing that the channel idiom is tailor-made
> for.
>
> i'm probably missing something.
> 

Re: [9fans] cooked mouse mode.

[rog]

> We wanted to make explicit to choose between cooked events or raw events, no 
> to expose the two interfaces at the same time, which may get applications
> into a kludge. You must choose cooked or raw, not being able to see both at 
> the same time.

just IMHO, i'd say that having the same channel produce two different
types of event is at least as open to confusion as having a new
channel and ignoring the old one.

by setting cooked mode, you are essentially changing the type of the
channel.  in the future you might wish cooked mode events to contain
other fields (for instance a "click count" to cope with more than
double mouse clicks), in which case your suggested interface would not
be sufficient - you'd have to change the definition of the Mouse
structure, which doesn't seem right.

i'm not objecting to putting the declarations in mouse.h in the
slightest; just that i don't think it's necessary to alter the old
interface.

doing it this way also opens the possibility of having various
different kinds of mouse cookery without affecting the original
interface or code in the slightest.

  cheers,
    rog.

Re: [9fans] cooked mouse mode.

[Fco. J. Ballesteros]

> just IMHO, i'd say that having the same channel produce two different
> types of event is at least as open to confusion as having a new

not quite.
You have to say
setmousemode(cooked),
and then no other thread has a way to get to
the raw mouse events.

Also, we'd like not to have different chefs for the mouse.

Re: [9fans] cooked mouse mode.

[rog]

> You have to say
> setmousemode(cooked),
> and then no other thread has a way to get to
> the raw mouse events.

except that a thread can read from the cooked mouse channel
and *think* that it's reading raw events, with no way
to tell.

if you're worried about it, you can just nil out the raw mouse
channel in the Mousectl structure.

Re: [9fans] cooked mouse mode.

[Fco. J. Ballesteros]

Well, actually the plan was to get applications use the
cooked mode; and get rid of the need for raw mode.
Agree that some will have to use it, say, like you do in
the console with the keyboard, but that's not the common
case. That can probably explain why we wanted a mode change
and not a new channel with different semantics for mouse events.

But maybe I'm missing your point, am I?

>> You have to say
>> setmousemode(cooked),
>> and then no other thread has a way to get to
>> the raw mouse events.
> 
> except that a thread can read from the cooked mouse channel
> and *think* that it's reading raw events, with no way
> to tell.
> 
> if you're worried about it, you can just nil out the raw mouse
> channel in the Mousectl structure.

Re: [9fans] cooked mouse mode.

[rog]

> Well, actually the plan was to get applications use the
> cooked mode; and get rid of the need for raw mode.

the nice thing about raw mode is that the relationship with what the
mouse is actually doing is beautifully simple and easy to explain.

"cooking" the mouse involves the application of a certain amount of
convention as to what sort of events one would like to see.

your convention assumes that applications are interested in clicking
and chording.

some applications might wish to know about other kinds of mouse
action, mouse gestures, or click-and-hold, perhaps.

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.

it seems right to me that the mouse events arrive in
lowest-common-denominator form, and than can then be transformed by
the application into whatever form is most convenient for that
application.  (it's just a pity that the Channel* type in C can't be
parameterised with the type of the value it holds).

keeping the transformation function separate is more modular.  it's
just the kind of reason that the channel-based model was used, surely?

Re: [9fans] cooked mouse mode.

[Gorka Guardiola]

>> Well, actually the plan was to get applications use the
>> cooked mode; and get rid of the need for raw mode.
> 
> the nice thing about raw mode is that the relationship with what the
> mouse is actually doing is beautifully simple and easy to explain.
> 
> "cooking" the mouse involves the application of a certain amount of
> convention as to what sort of events one would like to see.
> 
> your convention assumes that applications are interested in clicking
> and chording.
> 
> some applications might wish to know about other kinds of mouse
> action, mouse gestures, or click-and-hold, perhaps.

The language for cooked mouse is very general. Except for mouse gestures
if you want them without any button clicked, I think most of the things you
say can be used in cooked mode.

You have Click preffix, Slide events and many others (look at the
man page).

> 
> 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.


										G.

Re: [9fans] cooked mouse mode.

[rog]

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;
	};

Re: [9fans] cooked mouse mode.

[Fco. J. Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 75 bytes --]

Ok, your last argument convinced me.
I now agree with you. Thanks a lot.

[-- Attachment #2: Type: message/rfc822, Size: 3760 bytes --]

From: rog@vitanuova.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] cooked mouse mode.
Date: Fri, 14 Jan 2005 14:58:46 0000
Message-ID: <bc8c04c8073ac83c7cb40d6aa3926bb5@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;
	};

Re: [9fans] cooked mouse mode.

[Gorka Guardiola]

> paurea:

> 
> 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;
> 	};

We will have to rewrite the state to make it per-mousectl in order to
make multiple mouses possible (ouch!!), so we will consider all this.

Is there anything you didn't understand or you found badly explained
in the documentation or is it just the squeezing of things in the struct
which you are compaining of?.

Thanks to all for your suggestions and commentaries.



								G.

Re: [9fans] cooked mouse mode.

[rog]

> We will have to rewrite the state to make it per-mousectl in order to
> make multiple mouses possible (ouch!!), so we will consider all this.

surely the state can just be a local variable in the
function/thread doing the mouse processing?

does it need to know about Mousectl at all?

Re: [9fans] cooked mouse mode.

[Gorka Guardiola]

>> We will have to rewrite the state to make it per-mousectl in order to
>> make multiple mouses possible (ouch!!), so we will consider all this.
> 
> surely the state can just be a local variable in the
> function/thread doing the mouse processing?
> 
> does it need to know about Mousectl at all?


Hmm. I am not sure. There is more than one thread/function doing the processing.
For example, there is thread sending time events. Anyway it is one per mousectl
wherever it goes.

										G.

Re: [9fans] cooked mouse mode.

[Rob Pike]

The interface should be a wrapper for the existing interface,
one that takes a mouse interface and returns a cooked mouse
interface.  If possible, it shouldn't even depend on the existence
of mouse files and so on, but just on the channels that talk to
the mouse.   Concurrency is really about interfaces. Here you're
chaning the interface to a concurrent component by hacking the
interface. That's missing the point.

In other words, I agree with Rog's objections but have a purer
notion of how to approach the problem.

-rob

Re: [9fans] cooked mouse mode.

[Gorka Guardiola]

> 
> just IMHO, i'd say that having the same channel produce two different
> types of event is at least as open to confusion as having a new
> channel and ignoring the old one.
> 
> by setting cooked mode, you are essentially changing the type of the
> channel.  in the future you might wish cooked mode events to contain
> other fields (for instance a "click count" to cope with more than
> double mouse clicks), in which case your suggested interface would not
> be sufficient - you'd have to change the definition of the Mouse
> structure, which doesn't seem right.

> 
> i'm not objecting to putting the declarations in mouse.h in the
> slightest; just that i don't think it's necessary to alter the old
> interface.
> 
> doing it this way also opens the possibility of having various
> different kinds of mouse cookery without affecting the original
> interface or code in the slightest.


The set is more or less complete. There is already a click count in it
(see the MCHORDB macro). I don't think it can get much more complete than
it is now (though it may be shortsightedness on my part). Anyway, I don't think
you will want different ways of cooking the mouse for each application
more than a central one, because it can make things difficult to understand.
You can get lost asking how is this application cooking the mouse?

										G.

Re: [9fans] cooked mouse mode.

[Charles Forsyth]

suppose:
1. you're managing more than one mouse, and want different modes
2. you want to filter or transform a given raw mouse stream before cooking it

Re: [9fans] cooked mouse mode.

[Fco. J. Ballesteros]

> 1. you're managing more than one mouse, and want different modes

we're doing. Our mouse comes from /dev/mouse, which is serviced by mousefs
(a mouse redirector than handles multiple mouses).

> 2. you want to filter or transform a given raw mouse stream before cooking it

Isn't this `multiple recipes for cooking?'

Re: [9fans] cooked mouse mode.

[Gorka Guardiola]

>> 1. you're managing more than one mouse, and want different modes
>

Isn't what Mousectl is for?. You cook just one of them. Mousectl is a parameter to
setmousemode (did I get it wrong in the example?). See the manual in the patch for
more details.

setmousemode(Mousectl* mc, int mode)

> 
>> 2. you want to filter or transform a given raw mouse stream before cooking it
> 
> Isn't this `multiple recipes for cooking?'

Yep. This is what we wanted to stop.


									G.

Re: [9fans] cooked mouse mode.

[Gorka Guardiola]

>> 1. you're managing more than one mouse, and want different modes
>

Isn't what Mousectl is for?. You cook just one of them. Mousectl is a parameter to
setmousemode (did I get it wrong in the example?). See the manual in the patch for
more details.

setmousemode(Mousectl* mc, int mode)

> 
>> 2. you want to filter or transform a given raw mouse stream before cooking it
> 
> Isn't this `multiple recipes for cooking?'

Yep. This is what we wanted to stop.


									G.

Re: [9fans] cooked mouse mode.

[Gorka Guardiola]

>>> 1. you're managing more than one mouse, and want different modes
>>
> 
> Isn't what Mousectl is for?. You cook just one of them. Mousectl is a parameter to
> setmousemode (did I get it wrong in the example?). See the manual in the patch for
> more details.
> 
> setmousemode(Mousectl* mc, int mode)

Sorry, you are right. This state should be for each Mousectl... 

										G.

Re: [9fans] cooked mouse mode.

[Charles Forsyth]

> 1. you're managing more than one mouse, and want different modes

sorry, i meant in a single program.  it's not far fetched, and whether
mousefs would work depends on what the program does with inputs.
mouse.c and cook.c has introduced global state that wasn't there before
(previously avoided by having initmouse keep state in Mousectl
for each logical/physical mouse-input file)

Re: [9fans] cooked mouse mode.

[Fco. J. Ballesteros]

> (previously avoided by having initmouse keep state in Mousectl
> for each logical/physical mouse-input file)

setmousemode receives its own mousectl chan.
Is it ok in this case? Or do you think it's still wrong.
I

Re: [9fans] cooked mouse mode.

[Gorka Guardiola]

>> (previously avoided by having initmouse keep state in Mousectl
>> for each logical/physical mouse-input file)
> 
> setmousemode receives its own mousectl chan.
> Is it ok in this case? Or do you think it's still wrong.
> I


I have just seen it. The state of the interpreter should be per mousectl. There is a global
state which shouldn't be there in order to be able to cope with more than one mouse.

									G.

Re: [9fans] cooked mouse mode.

[Fco. J. Ballesteros]

> I have just seen it. The state of the interpreter should be per mousectl. There is a global
> state which shouldn't be there in order to be able to cope with more than one mouse.

Arggh!

I always thought the state was kept along with mousectl. I
agree that it's not a good way to do it if we keep goblal state.

We'll fix it, perhaps by using a different channel, as some of
you have suggested.

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.

thanks for your help

Re: [9fans] cooked mouse mode.

[Charles Forsyth]

> 2. you want to filter or transform a given raw mouse stream before cooking it

it depends whether all transformations or filtering can
be expressed in your language. for instance, in the past i've
changed the x and y values in such a way that results of tests such
as ismove, or double-button clicks, would be different.
in some cases, i could do that after cooking i suppose,
but since that potentially introduces time delays (to check
for clicks/chording) i'm not sure i could as easily say
what my transformation actually did (as easily as for
raw point values)

Re: [9fans] cooked mouse mode.

[Gorka Guardiola]

>> 2. you want to filter or transform a given raw mouse stream before cooking it
> 
> it depends whether all transformations or filtering can
> be expressed in your language. for instance, in the past i've
> changed the x and y values in such a way that results of tests such
> as ismove, or double-button clicks, would be different.
> in some cases, i could do that after cooking i suppose,
> but since that potentially introduces time delays (to check
> for clicks/chording) i'm not sure i could as easily say
> what my transformation actually did (as easily as for
> raw point values)

When you talk about the language you mean the implementation of cooked events or you mean
the actual events generated?.

The interpreter of events does not distinguish between X and Y movements, but it can be
done easily if it is needed.

										G.