Stefan Seefeld writes:
> 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.
Like SDL's "surfaces" ? I.e. non-visible places to draw stuff, maybe
blitting them to the visible screen/window at some stage, right ?
LibGGI has nothing like that yet (I hope it will someday). The
closest it comes is either using a large virtual area and drawing in
the off-screen parts, or using multiple frames and drawing in the
non-visible frame(s) using ggiSet{Read,Write}Frame.
> 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.
For an _application_ interface, I think it is reasonable to use this
concept of a "window" (also known as a "focus").
For something implementing that interface, like a windowing system,
yes it is reasonable for it to have direct access to the separate
input/output devices.
> > 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.
Have some mechanism to "join" input queues. Or poll. Or broaden the
concept of "focus" to allow multiple actual windows.
Cheers,
__
\/ Andrew Apted <[EMAIL PROTECTED]>
