Andrew Apted wrote:
> Personally, the idea of getting input "independently" of the output
> doesn't feel right. The traditional "window" is a good abstraction,
> it is a place to draw stuff for the user, and a place to receive the
> feedback from the user.
But you don't listen to a window for events. You listen to the server
connection ('XDisplay') for events which *refer* to windows. A window -
as it is seen by the application - is completely unaware of events.
Ok, let's assume that windows listen themselfs for events. Then there
are cases where you want to draw into some 'output only' medium, a
Pixmap in X. Since Pixmaps and Windows in X are the same for the purpose
of output (drawing), they are generalized to 'Drawables'. That's precisely
what I'm asking for.
To reiterate it once more: I can completely see your point of wanting to
glue input and output together. Yet I think The individual entities for
input and output should be accessible, even instantiable, through the
public API. You should not to be forced to by an input context just because
you need an output context.
> Think of each ggi_visual as a window if it
> helps (under the X target, it actually _is_ a window). Each "VT" on
> the console is also like a window (but text mode).
Well, from a practical point of view, how would I manage multiple input
queues ? Given a list of visuals (as you seem to suggest) acting as window,
I'd be forced into one thread per visual if I want to listen for events.
Stefan
_______________________________________________________
Stefan Seefeld
Departement de Physique
Universite de Montreal
email: [EMAIL PROTECTED]
_______________________________________________________
...ich hab' noch einen Koffer in Berlin...
