"Jon M. Taylor" wrote:
> > The argument is quite in line with Andreas' request to
> > refactor functionality in decompressing and drawing:
> > Drawing and event handling have *nothing* to do with
> > each other.
>
> Only in the sense that they are often bound to the same unit of
> human/machine interaction context. The right answer is to separate out
> the context handling into its own API system, which is basically what
> GGI/GII _is_. You can argue that the context unit should not be
> artificially bound to the concept of graphics or events coming from input
> devices, as you have done, but the fact that the word 'graphics' is what
> the middle 'G' in 'GGI stands for is really a historical artifact at this
> point |->. We manage contexts, resources and events these days.
That's fine. I'm not arguing against resource and event management as part
of GGI. I'm arguing against the constraint that each output context (drawable)
is bound to exactly one input context (event queue). If we ignore for a moment
expose events (which is a rather specific case which only happens in an
X like architecture where region management and drawing logic are separated into
different processes) we are left with input events, which have nothing to do
with drawing contexts. 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. 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'.
Well, as you know, that's not really what I'm looking for given that berlin
deals with region management (i.e. redrawing and 'picking' of scene graph nodes
for the purpose of focus management) internally so doesn't need this binding.
> > Berlin currently uses one Visual to draw into (via GGIMesa
> > or libArt) but I'd like to have offscreen drawables which
> > I can draw animations, videos and other things into before
> > I blend them into the scene graph.
>
> LibXMI should have what you need. The pixmap (sub-bitmap) system
> is still a bit fragile, but it's all there and should work. LibGWT will
> let you turn a ggi_visual into a "window" (= whatever you want) and route
> events around between them.
>
> > Even animated pointers
> > could be handled this way.
>
> Yup. Just allocate a memory visual and use it as a pixmap cache
> for pointers, stipples, GUI backing storage, etc.
Ok. So you are arguing that I in fact should use a visual as a drawable.
By the way, what is the relationship between libXMI (your version) and
GGI ? Is XMI one possible target for GGI to operate on ? Or would I use
it *instead* of GGI ?
Regards, Stefan
_______________________________________________________
Stefan Seefeld
Departement de Physique
Universite de Montreal
email: [EMAIL PROTECTED]
_______________________________________________________
...ich hab' noch einen Koffer in Berlin...
