From: Thomas Tanner <tanner@gmx.de>
  To  : ggi-develop@eskimo.com
  Date: Thu, 27 Aug 1998 12:35:56 +0200

new design (Re: LibGGI2D, LibGGI3D and targets)

Jon M. Taylor wrote:

> > That would make LibGGI useless.
>         By itself, yes, except maybe for the input stuff.  Again, I
> thought that was the idea.  I thought that LibGGI would handle the "glue"
> code - the concept of a visual with context, the generic API extension
> handling, the DirectBuffer stuff, and other such common, foundational
> code.  If this is *not* the case (which appears to be true), I would like
> to advocate that it become so.  Maybe not right now, but someday.  See
> below for more on why I think this is a good idea.

 Jon, you're absolutely right. You're having _exactly_ the same thoughts
like me.
 I often enough argued for moving all 2D functionality out of libggi
 (even directbuffer), moving events completely to libgii, 
 extensions having their own context rather than storing their data in
visuals
 etc.
 
 That's why I've written a specification for a new GGI design.
 Here are some excerpts of the README file and specification,
 which outline some of the differences to the "official GGI design":

Experimental GGI design
-----------------------

While the "official" GGI design has to take care of backward
compatibility this alternative design is completely incompatible with
the old one and emphasizes consistency, extensibility, flexibility,
abstraction and modularization. It is an experiment of new ideas and
might influence the further development of the official GGI libraries.
   
If you have any comments or want to help me then please contact me.
   
The lastest specification and snapshot can be obtained from
http://home.pages.de/~tanner/ggidesign.html

Overview/features:
------------------  

   general:
          
          + full multithreading support
          + support for static linking systems like DOS
          + error codes
          + very flexible configuration files
          + and much more...
            
   config scheme (thanks to Steffen Seeger):
          
          + very portable
          + dependencies
          + "make" from every directory
          + easy to understand
            
   LibGGI:
          
          + very high abstraction
          + no drawing functions, only visual managment
          + real color management
          + independent extensions
            
   GGI/FB (framebuffer):
          
          + fallback API, but not a must
          + no acceleration
          + supports also alpha- and Z-buffer
          + direct access possible but not recommened
            
   GGI/2D:
          
          + accelerated 2D functions
            
   GGI/GL:
          
          + full OpenGL API
          + Mesa completely integrated in GGI
          + multiple contexts
            
   GGI/Screen and GGI/Printer:
          
          + visual specific interfaces
            
   GII (input):
          
          + independent from GGI
          + gii_input as event source


 No API except the basic GGI interface is guaranteed to be available on
every visual.
 An application using GGI usually opens a visual, initializes it through a
visual 
 specific API and then selects a drawing API. Each drawing API has
 its own context so that several drawing APIs can be used at the same time. 
 However, due to limitiations of today's hardware, the simultaneous use of
more 
 than one drawing API should be avoided. 

 If there's no native driver for a drawing API then it tries to load some
 fallback-drivers, which emulate it on top of other drawing APIs,
 eg. GGI/GL on GGI/FB or GGI/2D.
 
 LIBGGI does not imply that the visual is 2D-ish.
 A visual is defined as:
 Any graphical object is abstracted by a ggi_visual. It can be a display,
printer, bitmap, 
 camera, movie, remote visual etc. i.e.
 everything that has optical characterics like color, shape, transparency, 
 intensity (brightness),  depht/structure, sharpness etc.
 A visual consists of an [in]finite number of elementary visuals (e.g
pixels, lines). 

 This way you can theoretically even draw on a real 3D object. You would
only need to
 have a drawing API for real 3D visuals. GGI/2D, for example, could then be
emulated on it.

> > From a purely abstract view, what you said is the ideal implementation, but
> > it is impractical.
>         I don't see why this is the case.

 Me, too. I'm just working on a implementation of it 
 and I really don't have any problems with it.
 
> > It's like microkernels -- they are supposed to be
> > minimal, but you still have to start somewhere.
>         Right, and that is why a core LibGGI should remain.  But the
> current situation is like the WinNT microkernel, which M$ shoved the video
> drivers into unnaturally.  Pull the video drivers back out of the NT
> kernel and you still have a small, focused microkernel that doesn't make
> assumptions about the nature of the device drivers.

 Exactly.

> > Does this answer your question?
>         Yes.  Thank you.  Let me assure you that I am not advocating
> ripping the guts out of LibGGI right now.  I am not necessarily advocating
> making *any* changes right now, aside from what stuff the LibGGI2D TO-DO
> file suggests.  But I would like people to think about what I have
> written.

-- 
Thomas Tanner -----------------------------
email: tanner@gmx.de tanner@ggi-project.org
web:   http://home.pages.de/~tanner
cool:  www.ggi-project.org  www.gnustep.org