Re: [9fans] cooked mouse mode.

["Gorka Guardiola Múzquiz" <paurea@lsub.org>]

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