From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <141f1f9a7cee225745d3eb7fb3ec3e67@plan9.escet.urjc.es> To: 9fans@cse.psu.edu Subject: Re: [9fans] cooked mouse mode. From: "Fco. J. Ballesteros" Date: Fri, 14 Jan 2005 15:57:13 +0100 In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-rtbubxfqlaxvlpwoqrnhwwjrpy" Topicbox-Message-UUID: 3065da9a-eace-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-rtbubxfqlaxvlpwoqrnhwwjrpy Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Ok, your last argument convinced me. I now agree with you. Thanks a lot. --upas-rtbubxfqlaxvlpwoqrnhwwjrpy Content-Type: message/rfc822 Content-Disposition: inline Received: from mail.cse.psu.edu ([130.203.4.6]) by aquamar; Fri Jan 14 15:52:17 MET 2005 Received: from psuvax1.cse.psu.edu (localhost [127.0.0.1]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 323CA63B2F for ; Fri, 14 Jan 2005 09:52:16 -0500 (EST) X-Original-To: 9fans@cse.psu.edu Delivered-To: 9fans@cse.psu.edu Received: from localhost (localhost [127.0.0.1]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 5539831E78 for <9fans@cse.psu.edu>; Fri, 14 Jan 2005 09:52:08 -0500 (EST) Received: from mail.cse.psu.edu ([127.0.0.1]) by localhost (psuvax1 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 14166-01-91 for <9fans@cse.psu.edu>; Fri, 14 Jan 2005 09:52:06 -0500 (EST) Received: from smtp.vitanuova.com (unknown [213.146.155.10]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 4788131A61 for <9fans@cse.psu.edu>; Fri, 14 Jan 2005 09:52:06 -0500 (EST) 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 X-Virus-Scanned: by amavisd-new at cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 9fans-bounces+nemo=lsub.org@cse.psu.edu Errors-To: 9fans-bounces+nemo=lsub.org@cse.psu.edu 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; }; --upas-rtbubxfqlaxvlpwoqrnhwwjrpy--