Stefan Seefeld writes:
> Ok, I admit that the overhead is not big. May be I'm not completely
> understanding what a visual is / is supposed to be. As I said, output
> and input are conceptually different. Input comes from one source, which
> I can watch by means of ggiEventSelect; output goes to any number of
> drawables I want to. So on this conceptual level I don't see why they
> are combined into one entity.
That was a design decision for LibGGI, as it covers most programs,
which (a) want to draw stuff and (b) want to get input from the user.
Quite a valid design IMO, other graphic libraries I know of do the
same thing (e.g. SDL, Allegro, Glut).
> I can, however, certainly live with an unused pointer in each 'drawable'
> I allocate for offscreen drawings. It just doesn't feel right.
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. 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).
Cheers,
__
\/ Andrew Apted <[EMAIL PROTECTED]>
