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