From mboxrd@z Thu Jan 1 00:00:00 1970 From: tlaronde@polynum.com Date: Fri, 20 Mar 2009 16:02:00 +0100 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20090320150200.GA2011@polynum.com> References: <2470057889c7c25d3cf6c0284b3bcc73@quanstro.net> <9f6b6afb208715c0f2db6433d94f8b21@terzarima.net> <20090320133704.GA1366@polynum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Subject: Re: [9fans] Raw Input Driver Topicbox-Message-UUID: c0ce2406-ead4-11e9-9d60-3106f5b1d025 On Fri, Mar 20, 2009 at 02:26:02PM +0000, roger peppe wrote: > > 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. In my design, there is a "virtual machine" (?), a software processing unit (?) on the terminal, stack based, so that when you are gathering events on a window, whether pointer location-based, or button events (location agnostic except for the window it is sent in), a task "returns" and can sent a software button event to dequeue the previous task on the stack that fires the processing. Or that can requeue an action if the data is not finished. For a kind of example, when drawing a line, you can just "point" a vertex (corresponding ground coordinates will be computed from window coordinates) or request to fasten on an element which means doing supplementary processing. In this case, on the terminal, the elements proposed for fastening are displayed and the user chooses. Only when the element is chosen, a request back (a "store") is sent since the representation of the elements is not homomorphe (i.e. due to scale, the drawing of a n vertex element is not perhaps a n vertex line on screen, so the mth vertex in the representation is generally not the mth vertex in the antecedent). The drawing task is dequeued and the processing fired. Only when, on the processing unit, the new vertex is computed, a new task is queued to continue drawing. I may misunderstand the point both due to my lacks in english and to the fact that I'm involved in my own implementation needs. But my software system is so large and touches so many different types of data, and needs to accomodate so many different types of UI, that I don't understand how a, at least chunk by chunk, terminal problem can not be terminal handled. At the moment, I have made improvements, and modifications (mainly simplifications); there are times when one can not avoid interrupting and sending to processing; but the principles hold. -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C