Re: [Guidolib-devel] Code Changes

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

At 08:43 03/02/2004, you wrote:

Hi Scott,


>I've made a few changes to the score engine code (a followup to the
>previous code reorganization messages), and I thought I would check with
>everyone before committing anything.

Do you want us to commit our changes first (about _getTagArgxxx
functions., naguido.cpp...) ?


>  I've fixed up the linux autotools
>and added a version checking m4 macro.  To support this macro, I've
>moved the version info from nview.h to GUIDOEngine.h and added two new
>version checking API functions - GuidoGetVersionNums, which returns the
>version number in three separate ints (the original GuidoGetVersionNum
>is still available); and GuidoCheckVersionNums, which checks the engine
>version number against an input (i.e. to make sure the library is of a
>sufficient revision).

Ok.

>After looking at the remaining items in nview.h,
>it seemed to make sense to take the remaining elements out of that file
>and deprecate it.

Good, those scattered headers were annoying.

>I took all of the external settings variables (i.e.
>gDisplaySprings, gDisplayForce, etc.) and moved them into a struct
>within GUIDOEngine.h, and then provided a gGlobalSettings variable with
>default values.

Ok, we were thinking about doing something like this. This is a good
Idea. Next step is probably to have separate settings attached to each
GuidoHandle, so two different Guido documents could have different
settings ( including page format...), i.e by adding a "settings" field to
the PairArMusic struct.


>The same was done with the remaining font variables
>(gFontScriab, gFontText, kDefaultMusicFont, kDefaultTextFont), put into
>GDeviceDefs.h in a gFontDefs struct.  It seemed a little cleaner this
>way, and better organized.

We would like to keep GDeviceDefs.h as Guido-independent as possible,
It there any other place where gFontDefs could be put ?

>Also, the linux compile now ignores
>naguido.h and naguido.cpp (which fixes the earlier unresolved symbol
>problem).  I've tested it on both my linux and windows system here, and
>everything compiles fine.
>
>I also had a question about version numbering.  What guidelines do you
>have for bumping the sub component of the version (i.e 1.2.x)?  Should I
>increase it to 1.2.1 due to the above changes (assuming they are ok with
>everyone)?

Now that the version 1.2 has been merged to the main branch, we are
all actually already working on the new version. It is ok to call it 1.2.1


>Finally, I'm going to firm things up with Holger, but it seems that the
>suggestion to do the GGS implementation through the VGDevice mechanism
>is a good one.  It would allow for the removal of the internal GGS
>functions (AddGGSOutput, etc.) and maintain a consistent graphic
>implementation for the score engine.  Does anyone use the currently
>existing GGS routines?
>
>Cheers,
>
>Scott

You can remove the internal GGS functions. We do not use it at all,
but we are interested in it. What are your plans for GGS ? do you have
specifications, drafts or something ?

Best,

Jerome