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:58:46 +0000 From: rog@vitanuova.com In-Reply-To: <2aa227a62be6922f84c49173dd179b88@plan9.escet.urjc.es> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 305fa2c4-eace-11e9-9e20-41e7f4b1d025 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; };