From: Marcus Sundberg <mackan@stacken.kth.se>
  To  : ggi-develop@eskimo.com
  Date: Sun, 30 Aug 1998 00:18:29 +0000

Re: LibGGI2D, LibGGI3D and targets

Jon M. Taylor wrote:
> 
> On Sat, 29 Aug 1998, Marcus Sundberg wrote:
>         Everything in CVS is a mess right now.  I suggest that we keep
> working until we all agree that a suitable stable state has been reached,
> and then we have Emmanuel blow away the whole CVS tree and reinstall
> everything without kgi/, os/, lib/libggi/extensions/libggi2d, etc and with
> any directory moves that we want done, done.  That will cost us our
> revision control, but we can archive the old tree if necessary and the
> cleanups will be worth it.

As Emmanuel has access to the server, isn't it possible to simply
move/delete directories in the local filesystem? Or is this
impossible?

> > The STUB libraries should always be loaded first by a target:
> > Let's say that you have a binary-only target from libggi 2.0,
> > that implements all libggi functions natively, and you upgrade
> > to libggi 4.0, in which we for some reason decided that a
> > ggiDrawParallelogram() function was badly needed.
> >
> > Now, the beauty of libggi is that as this target loads the
> > stub.so library, you can use the new ggiDrawParallelogram() function
> > even though the target doesn't even know it exists!
> 
>         I see.  But what if the API changes between versions?  Will the
> old 2.0 DrawBox() be ignored, for example?

If the API of DrawBox _changes_, an old target will cause undefined
results when used with new libggi. Maybe we should add versions to
targets and other libraries too, to prevent an incompatible
library from being loaded?

A new target used with an old libggi can handle the situation by
providing both DrawBox() implementations and use the GGI_VERSION_FUNCS()
macro to check which one to use.

If DrawBox() is removed, and old target with new libggi will cause
the DrawBox in the target to be unused, as there is no ggiDrawBox
symobl in libggi. In this case you shouldn't use an old libggi with
new targets - libggi is opensource and can always be upgraded.

>         Right.  Even if the stub code draws everything using PutPixel(),
> PutPixel() still has to know about the visual layout to know what a pixel
> *is* and how to draw it.  I assume this means that all targets must
> implement PutPixel() for all mode types in the stubs?

Yes, or at least for all modes that the target supports.

//Marcus
-- 
-------------------------------+------------------------------------
        Marcus Sundberg        | http://www.stacken.kth.se/~mackan/
 Royal Institute of Technology |       Phone: +46 707 295404
       Stockholm, Sweden       |   E-Mail: mackan@stacken.kth.se