Re: [Guidolib-devel] GGS Implementation

[Jerome B. <be...@gr...>]

At 06:11 15/02/2004, you wrote:

Hi Scott,


>...
>I 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.

         As I remember, the initial gdevice is here to create a font at 
startup,
which is required in a few GR-class constructors to preprocess things related
to character width and height. I already had a quick look at how to remove it,
but it was not straightforward.


>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.

As long as the current GuidoOnDraw + VGDevice mechanism is not broken,
that's ok for us.

Best,

Jerome