From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@cse.psu.edu Subject: Re: [9fans] cooked mouse mode. Date: Fri, 14 Jan 2005 14:26:28 +0000 From: rog@vitanuova.com In-Reply-To: <9f78f30e1a29903f8c6f43d685b83110@plan9.escet.urjc.es> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 2fb1ebde-eace-11e9-9e20-41e7f4b1d025 > 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?