> I have argued in the past for a more formal separation of LibGII
> from LibGGI. This would decouple the event queues from ggi_visual(s).
Actually they are separated. LibGII provides all event functionality.
All that LibGGI does is automatically locate and load the approriate
"default" event sources for a given target.
After that you are free to do anything to them. Close them down (o.k. -
that's not strictly supported, but could be added easily, if required) join
more inputs, ...
> > Sure, the notion of a window (as in X) is a combination
> > since you can draw into it and be sensitive to events *for* it.
> A window is just a particular set of rules for representing the
> contents of a particular graphics context. Each window is bound to a
> ggi_visual in LibGWT and they route events amongst themselves just fine.
Yep. That is the idea, cube3d also shows how you can multiplex the event
streams. The apps on the sides of the cube get all fed by the main event
stream from the visual the cube is on.
> > But this consideration should come *after* input and output logic has
> > been defined, i.e. a 'window' should then be constructed as, say, a
> > pair of a drawable and a 'hot region'.
This can be done easily in application context.
CU, ANdy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
