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) <tlaronde +AT+ polynum +dot+ com>
http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
