Jon M. Taylor writes:
> Bugreports and patches are appreciated.
Okidoke: demos/demo gives me a short line of three dashes on the
screen, then it segfaults with the missing symbol as you said.
xmitest segfaults immediately with a missing symbol.
> The first and most important problem area is contextual clashing
> between LibGGI and LibXMI. LibGGI's basic unit of context is the
> ggi_visual, while LibXMI stores contexts in three basic types: miGC,
> miCanvas and miPaintedSet. An miGC stores styles for dashes etc as well
> as some pixel typing abstractions, an miPaintedSet is an opaque type which
> holds span descriptors in the current XMI soft-implementation, and an
> miCanvas encapsulates a "drawable" (DirectBuffer) and a set of rules for
> drawing a PaintedSet. Only the miPaintedSet type is really designed to be
> swapped out for another opaque type, and that at compile time. All of
> this mess has to be reconciled with the ggi_visual concept, either by
> removing one or more of the XMI context types and placing their member
> fields into the ggi_visual private structs, or by figuring out how to
> properly encapsulate the contexts inside of each other.
I think it depends on what you are doing with XMI. Are you creating
something that is supposed to be compatible with existing programs
that use XMI ? (I'm guessing no).
If not, are you creating something new based on the old XMI code,
something new which sits nicely on the side of LibGGI as an extension,
with an API that is "inspired" by XMI ? (I'm guessing yes).
If so, then you're free take a hefty axe to the crufty preprocessor
hackage (autoconf can handle such things much better), and to
generalize the needlessly non-generalized XMI drawing abstractions.
Still with that assumption:
- I think miGC should just be internalised as a single GC, like an
extension to LibGGI's normal GC. That makes it consistent with
LibGGI and simplifies simple applications, with the downside that
complex applications are potentially more complex and slower with
GC thrashing.
- The miCanvas is just the ggi_visual_t, like you have now.
- The miPaintedSet is the interesting one. I think support for
multiple painted sets is worth having, you could imagine a game
where each painted set is an on-screen object.
The API could be simplified though by having a "current painted
set" (not unlike libggi's current write frame). Maybe use integer
handles for them (e.g. you could allocate or delete a whole range
at once), not sure if its better than pointers though.
Cheers,
__
\/ Andrew Apted <[EMAIL PROTECTED]>
