[Guidolib-devel] GGS Implementation

[J. S. A. <js...@sh...>]

Hi All,

Holger and I have finalized our approach for the GUIDO Graphic Stream,
and I thought I would invite some comments.  Although we did initially
consider the idea of developing a VGDevice implementation of the GGS,
Holger felt it would be unnecessarily low-level and verbose.  So, I have
been charged with investigating what would be required to allow both the
VGDevice strategy and a separate GGS implementation to coexist
peacefully! :-)  This also coincides well with some of my previous work
at reorganizing some of the headers.

It seems to me that it would not take too much effort to make the engine
VGDevice independent, and then provide alternate drawing routines to
produce a GGS stream.  The two main structs that seem to call for a
VGDevice are: GuidoInitDesc and GuidoOnDrawDesc.  The latter is
obviously required for all of the OnDraw routines currently in use, and
would remain unchanged (and the GGS OnDraw routines would parallel these
existing routines).  It is the initial VGDevice in GuidoInitDesc that
would be removed.  This VGDevice seems to provide only a few font
related items and access to two routines: GetScreenTextExtent and
GetScreenSymbolExtent.  Judging by some of the in-code comments, these
two routines are set for deprecation anyways (and I'm not exactly sure
what they are used for)?  And since the VGDevice passed here doesn't
actually seem to be responsible for any drawing (in deference to the
GuidoOnDrawDesc), it is a bit redundant.

So, my idea is this: (1) to move gFontScriab, gFontText,
kDefaultMusicFont, and kDefaultTextFont into VGDevice.h (from their
current temporary spot in GDeviceDefs.h); (2) remove the VGDevice from
GuidoInitDesc; (3) move any of the font initialization that occurs in
GuidoInit to GuidoOnDraw; and (4) implement a parallel set of OnDraw
routines to output GGS along with adding a GuidoOnDrawGGS or similar API
routine.  The choice of which draw routine to use (GGS or VGDevice)
would then be left up to the API user.

With respect to the GGS, every item that gets drawn on screen would then
have a GGS output routine, which would essentially consist of writing a
string to a stream (very much as the existing GGSOutput routines).  This
stream could then be written to a file, or sent across a network, etc.
A more detailed GGS specification will follow as things progress.

Please let me know what you all think about this approach.

Cheers,

Scott