From: Andrew Apted <ajapted@netspace.net.au>
  To  : ggi-develop@eskimo.com
  Date: Thu, 27 Aug 1998 22:28:12 +1000

Re: LibGGI2D, LibGGI3D and targets

Jon writes:

>  	That I can see.  Events are a totally independent item.  Of course
>  it can be argued that events should have their *own* library.

Disagree.  Events are not independent, and I can't see how they ever
_could_ be independent -- on a windowing system (e.g.) you get events
via the same window handle you use to draw with.  On a tty device, you
get keyboard input from the same fd that you write characters to.

>  I thought
>  that was what LibGII was for, but people are saying that LibGII is DOA. 

LibGII was never about getting events from targets, but providing a
framework for _handling_ events in a configurably consistent manner.

>  I will just tell
>  the LibGGI2D target to render some lines.  Specifics of 2D buffer layouts
>  and 2D drawing commands are not part of LibGGI3D.  Ergo, I will not be
>  using those sub-libraries in LibGGI3D.

Precisely.  No problem there.

>  > LibGGI2D is supposed
>  > to be "advanced" 2D functions -- for example, it has polygons, circles,
>  > alpha values.
>  
>  	I thought it was to handle *ALL* 2D stuff of any kind.  If you
>  want to separate low-level 2D stuff like basic framebuffering, the concept
>  of a pixel, clipping, etc from the higher-level LibGGI2D stuff (arcs,
>  polygons, alpha, etc), I would advocate having a LibGGI2D-basic and a

LibGGI *is* libGGI2D-basic.  You don't get any more basic that pixels,
lines and boxes in solid color.

LibGGI2D is for all the non-basic stuff, like curves, polygon outlines,
filled polygons, stretching, etc... all with different drawing modes
(and,or,xor) and fill-patterns, alpha support, dotted-lines ETC.  Once
all this is fully implemented and optimized for some common cases, it is
going to be *HUGE*.  Way too much bloat for many libggi programs that
only want the basics.

>  Let me assure you that I am not advocating ripping the guts out of
>  LibGGI right now.

Good, 'cause right now I'm _really_ looking forward in releasing a fully
functional LibGGI to the "public" (so to speak), and getting it into 
distributions like Red Hat and Debian, and having more people get
interested in it and write programs for it, and to see this mother fly.

Making really big / fundamental changes to LibGGI is only going to set
us back _another_ 6 months.  It's not worth it IMHO, LibGGI is good
enough right now IMNSHO.

Cheers,
_____________________________________________  ____
                                               \  /
  Andrew Apted   <andrew@ggi-project.org>       \/