From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <20090320133704.GA1366@polynum.com> References: <2470057889c7c25d3cf6c0284b3bcc73@quanstro.net> <9f6b6afb208715c0f2db6433d94f8b21@terzarima.net> <20090320133704.GA1366@polynum.com> Date: Fri, 20 Mar 2009 14:26:02 +0000 Message-ID: From: roger peppe To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Raw Input Driver Topicbox-Message-UUID: c0b2fb4a-ead4-11e9-9d60-3106f5b1d025 2009/3/20 : > On Fri, Mar 20, 2009 at 01:03:12PM +0000, roger peppe wrote: > For my own stuff, having to rewrite the 2 dimensions user interface, I > have created a library running on the terminal that keeps the > definitions of the graphical elements drawn with an identifier (3 > members) giving to the processing unit (remote) a mean to unambiguously > identifies the antecedent for processing. that's fine for location-based events, e.g. from a mouse, (well, fine for largely static UIs) but still leaves unresolved the issue of how do deal with events that are agnostic about their destination, such as keyboard events. you can't decide which graphical element a key press is destined for until you know the mouse language of your application. acme has both click-to-type and point-to-type - the client would need to know which one to use, otherwise you still have exactly the same ordering problem as before.