LibXMI is now available via public CVS, with both anonymous
read-only and account-based read/write capability. Point your CVSROOT
thusly:
CVSROOT=:pserver:<username>@tanuki.dhs.org:/usr/local/cvsroot
'<username>' shoould be replaced with 'cvsguest' unless you have
an account with commit privileges on tanuki (currently only me). The
password for cvsguest is also 'cvsguest'. The module name is 'libxmi'. If
you want commit privs, please mail me a crypted passwd entry and I'll get
you set up. Serious developers only please.
What's in the repo right now is the newest snapshot. The build
and install process is working properly now, although currently you must
'./configure --disable-x' to avoid triggering some compile-time bugs in
the X target which is not even used yet. The external API is now complete
enough to run the two included demo programs, although the internal stubs
implementation does not properly export many of the functions yet, thus
causing unresolved symbol errors at runtime. This should not be too hard
to fix, just time-consuming. Once that is fixed, theoretically the stubs
code (which is mostly the original XMI code with GGI-enabling QuickHacks
in a few places) should work and demo.c should draw some colored arcs on a
GGI visual in most any target environment. Bugreports and patches are
appreciated.
One that point is reached (hopefully tonight), several pending
design issues will need to be worked out before development can proceed
much further. I'd like to solicit some public feedback on these points.
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.
Second, there is some really crufty old preprocessor hackage in
their to support old C compilers with no void type (!) and no function
prototypes (!!!) and even standard library functions wrappers (?!?) and
plenty of other such ancient-ness. I have cludged around this for now and
managed to hide this nastiness from the LibXMI calling environment, but I
would really like to take an axe to all that stuff. I do not think it is
reasonable to continue to support non-ANSI compliant C code in the year
2000, especially open source code. I would like to see what the author of
LibXMI has to say about this.
Third, some of the existing XMI drawing abstractions are
needlessly non-generalized. Stipples and textures and such are really
generic examples of pluggable LUT algorithms, and right now they are
explicitly defined in data types instead of being defined with a namespace
and pointer casts.
That's all for now. I'll be back soon to do some more work.
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
