On Mon, 17 Apr 2000, Stefan Seefeld wrote:
> "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).
You can easily split, join and route event streams in LibGGI.
This lets you mux/demux event streams based on whatever logic you like,
independent of the fact that there's one serialized stream of events
flowing into each visual.
> 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.
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).
>From a design standpoint this would be a more elegant solution than adding
mux/demux logic to handle multiple event types a la Win32. But it isn't
strictly necessary.
> 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.
> 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'.
Shades of EvStack/GGI Console. Redefine everything as a message
switching fabric.
> 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.
Sure.
> > > 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.
Yes.
> By the way, what is the relationship between libXMI (your version) and
> GGI ?
LibXMI is a GGI extension library. It is initialized and attached
to an existing ggi_visual, hooking its own private context info to the
visual struct. One can then call the XMI functions to draw onto the
visual.
> Is XMI one possible target for GGI to operate on ?
No. The reverse actually, the "unaccelerated" default stubs
drawing routines for LibXMI call LibGGI drawing functions. In this way,
dependencies between GGI and its extensions, or extensions and other
extensions, can be fixed.
> Or would I use
> it *instead* of GGI ?
You would use it in addition to LibGGI.
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
