guidolib-devel — The list is for discussion about development issues and API design.

[Guidolib-devel] a Guido gtk device for linux

[Dominique F. <fo...@gr...>]

Hi all,

goog news: thanks to Torben Hohn, a guido gtk device for linux is 
available on the guidolib repository.
This device is to be completed and improved but it already works: a 
very simple (draft) guido viewer based on this device has also been 
added to the repository.

best,
--dom

[Guidolib-devel] FASD project: Online survey launched

[<ben...@id...>]

Dear Open Source developer

I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate.
You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it.

With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development.


With many thanks for your participation,
Benno Luthiger


PS:
The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/.
We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list.

_______________________________________________________________________

Benno Luthiger
Swiss Federal Institute of Technology Zurich
8092 Zurich

Mail: benno.luthiger(at)id.ethz.ch
_______________________________________________________________________

[Guidolib-devel] Guido API

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

Hi,

  We are about to release a SDK for Guido. The current API needs a few
adjustements, in order to keep it clean and simple. Following changes
are on the way:

- GuidoAdjustPageSize() will be renamed GuidoResizePageToMusic()

- GuidoSetAutoBeam(), GuidoSetSpringParameter(), GuidoSetOptForce(),
GuidoSetNeighborhoodSpacing(), GuidoSetOptPageFill() and their "Get"
equivalents will be removed. These settings will be accessible via the 
existing
GuidoSet/GetSetting( id, value ) function instead.

- GuidoSetDefaultPageSize( char * sizex... will use float types instead of 
char *

- The deprecated int GuidoGetVersionNum() will be removed.

- The obsolete field "isprint" of the struct GuidoOnDrawDesc will be removed.

- Giving the GPaintStruct "erase" field a more explicit name.


Any remarks and suggestions are welcome.


Jerome

[Guidolib-devel] Variations2 project

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

At 16:57 05/05/2004, you wrote:

Hi,


>As I told you already Don Byrd (I hope you know him otherwise please have 
>a look: http://php.indiana.edu/~donbyrd/ )
>wants to use midi2gmn and gmn2gif for creating small gif files from 2500 
>MIDI files in context of the Variations2 project
>( http://variations2.indiana.edu/  ).
>
>I helped him with optimising/solving  some issues with creating score 
>.gif's  for small resolution display (i.e., I compiled him a special 
>gmn2gif version using blue instead of black staff lines.)

  I had excellent results with Gif export, by generating pictures at twice 
(or more) the target
resolution, say 1000x1000, then reduce it with graphic software to 500x500 
pixels with high
quality resampling (bilinear...). The result of this is a nice non-aliased 
music score, you can
even tune up the final result with a sharpen filter. You also avoid those 
kind of little but annoying
aligmenent imperfections.

  The shareware GraphicConverter (MacOs) is the perfect solution for this, 
it can convert and/or
modify thousand of files at once, and fast.

About gif export, the maximum size in the NoteViewer is now 3200x3200 
(instead of 1600x1600).


>It turned also out, that if avoiding the 5-staffline character for system 
>drawing (using single line symbold instead) the output quality in terms of 
>equal spaced stafflines is much better!
>It might be that the lines are not equally spaced in the font.

  In the current version of the library, Guido does not use a font 
character anymore to draw
the staff. It just draws n lines with a "pen". Both solutions have issues 
at small resolution,
but using above method (large images + downsampling) probably leads to 
acceptable results.


>Some issues could not be fixed right know (number of beams for strange 
>tuplets, etc.).
>
>After reading the changelog.txt of the GUIDOLib he'd like to ask/discuss 
>with you about plans, possibilities, etc. for improving the default 
>positioning of tuplet numbers and brackets.

  The new Windows GuidoViewer v0.92 has just been released today on 
sourceforge (main and
dev branches have been merged, mac version is planed for tomorrow), among 
other things,
automatic positioning of tuplet numbers and brackets has been implemented. 
We can now
discuss about their improvement. Of  course, all suggestions are welcome.

Regards,

Jerome

Re: [Guidolib-devel] Re: GGS & GDevicePostScript

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

On Mon, 2004-03-15 at 04:41, Dominique Fober wrote:
> The branch has been created, You'll have to checkout the ggs branch and  
> to transfer your changes to this branch
> before committing.

OK - I have done so.  This branch now contains the GFontManager
changes.  I have done some more testing, mostly with the
GDevicePostScript (and GFontMangerPS), and it seems to work quite well. 
I have checked in the GFontManagerWin32, but I have not altered any of
the win32/application code, nor done any testing on that side.  And
finally, I have created a GuidoGGSFactory object that assembles and
streams the GGS code (which has been put in OnDrawGGS routines parallel
to many of the OnDraw routines).  I'm waiting for Holger to approve the
current list of GGS commands, but most of the basic elements are
implemented (i.e. noteheads, stems, clefs, beams, etc.)  Still to come
are flags, articulations, dynamics, slurs/ties and text.

Cheers,
Scott

Re: [Guidolib-devel] Re: GGS & GDevicePostScript

[Dominique F. <fo...@gr...>]

Le 11 mars 04, =E0 20:32, J. Scott Amort a =E9crit :

> At this point, I would like to have you and the others take a
> look at what I have done and comment, but I think it may be prudent to
> create a new branch in the cvs for this (perhaps a ggs branch as I =
will
> begin to add in routines for that quite soon).  This way the current =20=

> dev
> branch will not be broken, and when things progress enough on the ggs
> branch a merge can be examined.  What are your thoughts?

No problem, concerning the branch. I propose to adopt you suggestion
and to create a ggs branch on the dev branch. The development tree =20
structure will
be the following:

     main
      |
      |\ dev
      | \
      |  \
      |   |  ggs
      |   |\
      |   | \
      |   |  \
      |   |   |

The branch has been created, You'll have to checkout the ggs branch and =20=

to transfer your changes to this branch
before committing.

dom

------------------------------------------------------------------------=20=

---------
Dominique Fober                                                  =20
<fo...@gr...>
GRAME - Centre National de Creation Musicale -
9 rue du Garet 69001 Lyon France  tel:+33 (0)4 720 737 00 fax:+33 (0)4 =20=

720 737 01
------------------------------------------------------------------------=20=

---------

[Guidolib-devel] Re: GGS & GDevicePostScript

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

Hi Jerome,

On Fri, 2004-03-05 at 02:28, Jerome Berthet wrote:
>          - Splitting GDevice in two classes: one for vector graphics 
> (GDevice), and
>            one for fonts management i.e: GPlateformFontMgr. The GDevice could
>          embed its FontManager (thus, that would similar to the current 
> implementation),
>          then GuidoInitDesc would just require a FontManager. Providing a 
> graphic device
>          at initialisation is definitely strange, but providing a font 
> manager would make
>          more sense. I think it would not be too much work to convert 
> existing devices to
>          this design. What do you think about it ?

I've gone ahead with this implementation.  It appears to work fine (that
is, it compiles, I haven't done any real form of exhaustive testing :-)
).  What I have done is create a GFontManager class that contains the
font and bitmap routines (the bitmap routines are really just stubs as
it doesn't seem to be fully implemented yet).  The GuidoInitDesc now
only requires the GFontManager instead of the VGDevice.  The base
GFontManager reads in a file that contains font metric data and uses
that to implement the various GetScreenExtent, GetTextExtent, etc.
routines.  Then, similar to the VGDevice model, child classes can be
created (i.e. GFontManagerWin32, GFontManagerPS, etc.) that override
those routines with their device specific implementations.  As well, I
have embedded a GFontManager instance (gFontManager) into VGDevice, so
that when any graphic device object is created, it attaches a font
manager to itself.  This has allowed for very minimal code changes,
mostly just relocating routines and creating a few pointers to the new
objects, while still allowing for a device-independent interface with
which to implement the GGS.  However, it will break all the current
applications/libraries due to the addition of a required GFontManager
pointer to the VGDevice constructor as well as the change in
GuidoInitDesc.  I have implemented the base GFontManager, a
GFontManagerPS (postscript), GFontManagerWin32 (win32) and
GFontManagerWin2000 (win2000), however, I have not altered any of the
applications.  I don't believe it will be terribly difficult to fix
these, I just haven't done so yet.  Additionally, my familiarity with
OSX programming is very minimal, so I have not yet approached that
aspect.  At this point, I would like to have you and the others take a
look at what I have done and comment, but I think it may be prudent to
create a new branch in the cvs for this (perhaps a ggs branch as I will
begin to add in routines for that quite soon).  This way the current dev
branch will not be broken, and when things progress enough on the ggs
branch a merge can be examined.  What are your thoughts?

Cheers,

Scott

[Guidolib-devel] [Fwd: commandline options?]

[Kai R. <dr....@we...>]

Hello,

can someone be so kind and answer the attached e-mail?

Thank you and greetings from

Kai Renz

[Guidolib-devel] Fwd: GGS & GDevicePostScript

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

(From: "J. Scott Amort" <js...@sh...> )

>Hi All,
>
>I've been slowly working away here on the GGS implementation, and have
>been investigating the best way to create a platform-independent
>implementation.  Since it appears that some manner of VGDevice is
>required for the engine to function (removing the VGDevice from
>GuidoInitDesc is quite troublesome, so perhaps it is best to leave it
>be!)  Therefore, it would seem that using GDevicePostScript may be the
>best candidate for not breaking anything while still having access to
>the font information necessary for GuidoInitDesc (and, postscript output
>is also on my list of things to do).  What is the state of the
>GDevicePostScript code?  Is it ready to go, or does it need more work?
>If the latter, I'll happily volunteer to work on it, if someone can
>bring me up to speed on where it is at.  Thanks!
>
>Cheers,
>
>Scott

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

[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

Re: [Guidolib-devel] Code Changes

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

On Thu, 2004-02-05 at 09:18, Jerome Berthet wrote:
> But for now you can let gFontDefs in GDeviceDefs.h if other solutions
> cause too many problems.

Ok - I've left it this way for now and checked in my changes.  I'll
investigate reorganizing the headers as well as adding the
gGlobalSettings to the PairArMusic.

Also, I came across a typo in one of the header files (can't think of
which one off the top of my head) that included "GuidoExport.h" instead
of "GUIDOExport.h".  I fixed it, but perhaps a standardized approach to
the capitalization (or non-) of GUIDO in file names might not be a bad
idea.

Cheers,

Scott 

Re: [Guidolib-devel] Code Changes

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

At 17:24 05/02/2004, you wrote:

Hello,

>I realize now why I put gFontDefs in GDeviceDefs.h - it needs the
>GFontRef/GFontInfos class which is defined there.  To include it in
>GUIDOEngine.h would either require moving those classes or adding an
>#include to GUIDOEngine.h, which is undesirable as it would necessitate
>distributing two extra and unnecessary header files with the library.
>Any ideas?

   I had a lot of fun too with those headers. Maybe it's time for the big
spring cleaning. As you just say, it's better to keep separate
"public" and "internal" headers. The game is to have a minimal set
of public headers, minimum dependencies and a fast compile time.

Maybe you could deal with remaining headers that are still not
in /src/include :

/lib-score-engine/defines.h
/parser/guido.h
/parser/GuidoDefs.h

remove some (just as you did with nview.h), maybe create a brand
new one properly placed in /include. Yet another include file is
/include/GUIDOTypes.h

But for now you can let gFontDefs in GDeviceDefs.h if other solutions
cause too many problems.

Cheers,
Jerome

Re: [Guidolib-devel] Code Changes

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

Hi Jerome,

On Tue, 2004-02-03 at 03:09, Jerome Berthet wrote:
> We would like to keep GDeviceDefs.h as Guido-independent as possible,
> It there any other place where gFontDefs could be put ?

I realize now why I put gFontDefs in GDeviceDefs.h - it needs the
GFontRef/GFontInfos class which is defined there.  To include it in
GUIDOEngine.h would either require moving those classes or adding an
#include to GUIDOEngine.h, which is undesirable as it would necessitate
distributing two extra and unnecessary header files with the library. 
Any ideas?

Scott

Re: [Guidolib-devel] Code Changes

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

At 01:00 05/02/2004, you wrote:

Hi,


> > 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.
>
>Interesting.  I'll have a look at this and see about extended my
>alterations to include this, if you prefer.

This was just an idea I wanted to share with you. You can do it if you
have time and think it's better.

> > We would like to keep GDeviceDefs.h as Guido-independent as possible,
> > It there any other place where gFontDefs could be put ?
>
>Sure, I could just add it to GUIDOEngine.h as a similar settings struct,
>and perhaps place it in the PairGR?

Ok for GUIDOEngine.h, and in PairGR if you think it's more appropriate.


>  ...... Once something is solidified, I will certainly pass it
>on to the list.

Thanks,
Jerome

PS: we've commited our changes on cvs.

Re: [Guidolib-devel] Code Changes

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

Hi Jerome,

On Tue, 2004-02-03 at 03:09, Jerome Berthet wrote:
> Do you want us to commit our changes first (about _getTagArgxxx
> functions., naguido.cpp...) ?

Sure, it shouldn't make too much difference - I have removed the files
from the build list, but not actually physically altered them.  However,
it might be good for me to make sure everything is ok with the latest
changes.

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

Interesting.  I'll have a look at this and see about extended my
alterations to include this, if you prefer.

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

Sure, I could just add it to GUIDOEngine.h as a similar settings struct,
and perhaps place it in the PairGR?

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

I believe the initial reason for the GGS was to provide a platform
independent means of graphic output from the score engine.  However,
since you have achieved that already with the VGDevice class, it's role
will be a bit different! :-)  My thoughts are that it provides a means
to modularize the engine and an interface.  A developer could build a
graphic front-end for Java, say, or some other currently unsupported
graphic device without having to extend the engine (although that would
also be possible).  I'm waiting for Holger to get back to me about
approaching the GGS through a VGDevice, as that will affect the
specification.  Once something is solidified, I will certainly pass it
on to the list.

Cheers,

Scott

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

[Guidolib-devel] Code Changes

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

Hi All,

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

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

[Guidolib-devel] Graphic devices mechanism.

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

=============================================================================
   Quick note about Guido graphic devices (GDevices)
=============================================================================

This note describes the mechanism currently used by the Guido Engine Library
to display graphics. i.e: how to generate visible score pages, starting from
an internal Guido Graphic Representation structure (Guido GR).

In the first version of the GuidoEngine, a Windows HDC type (graphic device
context handle) was provided to the GR objects, that were directly calling
microsoft APIs to display vector graphics and text.

For the GuidoEngine to be platform-independent, and to avoid being restricted
to only one graphical technology, (even a cross-platform one such as pdf, eps
or OpenGL ...), the choice has been made to provide a c++ object (called
VGDevice) to the GR objects, in place of the previous windows HDC handle.

VGDevice is a c++ pure virtual class that declares all methods required by the
GR objects to communicate their graphical operations. Implementations of
VGDevices are provided by clients applications via derived classes (i.e:
GDevicePostScript, GDeviceWin32...), so that neither GR objects nor any part
of the GuidoEngine depend on a particular graphical implementation.

The main advantage is that VGDevice derived classes can implement any kind of
graphical output : on-screen (platform specific, OpenGL), off-screen (raw
bitmaps), files (pdf, svg, postscript), network streams...

VGDevices derived classes must provides standard graphical functions (Lines,
Arcs, Boxes,Polygons, Text), coordinate transformations (zoom / scaling), and
symbolic music symbols handlers (DrawSymbol method). VGDevice design makes a
clear distinction between text characters and music symbols (although music
symbols are generally glyphs in a music font). Music symbols are identified by
font-independent constants (see MusicalSymbols.h). This mechanism provides
VGDevice objects with a higher abstraction level than a pure graphic layer.


Existing implementations of VGDevices:

GDeviceOSX:             MacOS X Quartz implementation.
GDeviceWin32:           Windows 95/98/Me (gdi)
GDeviceWin2000:         Windows 2000 / XP(gdi+)
GDevicePostScript:      EPS files (encapsulated postscript)
GDeviceWx:              wxWindows DC implementation.

Planned:

- OpenGL gdevice.
- Bitmap and Gif gdevices.

(This document has been posted to CVS, in the doc directory)

Re: [Guidolib-devel] Code reorganization

[Dominique F. <fo...@gr...>]

Hi Scott,

Le 23 janv. 04, =E0 21:28, J. Scott Amort a =E9crit :
>
> I was doing a bit more testing with the Linux library, and discovered
> some problems with the shared library and some unresolved symbols (the
> static library works fine because it doesn't require all symbols to be
> resolved):
>
> /usr/local/lib/libguidoengine.so: undefined reference to
> `gd_getTagArgFloat(int)'
> /usr/local/lib/libguidoengine.so: undefined reference to
> `gd_getTagArgName(int)'
> /usr/local/lib/libguidoengine.so: undefined reference to
> `gd_getTagArgType(int)'
> /usr/local/lib/libguidoengine.so: undefined reference to
> `GuidoCheckForFont(char const*)'
> /usr/local/lib/libguidoengine.so: undefined reference to
> `CreateDefaultGDevice()'
> /usr/local/lib/libguidoengine.so: undefined reference to
> `gd_getTagArgInt(int)'
> /usr/local/lib/libguidoengine.so: undefined reference to
> `gd_getTagArgUnit(int)'
> /usr/local/lib/libguidoengine.so: undefined reference to
> `gd_getTagArgStr(int)'
>
> I've traced these, and the gd_* functions are referenced in the =
guido.h
> header file (in the parser directory), but are actually defined in the
> Gmn2MidiParser.cpp file (in the lib-guido2midi directory).  And the
> GuidoCheckForFont and CreateDefaultGDevice are referenced in the
> GUIDOEngine.h header file (prior to a platform dependent comment!) and
> both are defined in GUIDOMainCarbon.cpp and GUIDOMainWin32.cpp
> (depending on platform).

The gd_getTagArgxxx functions problem comes from historical reasons:=20
when the
open source project started, several parsers were co-existing. The=20
parser/naguido.cpp and .h files seems to be part of the remaining=20
inconsistencies since they're only used by the gmn2midi project which=20
also declares and implements the gd_getTagArgxxx functions.
I propose to move the naguido.cpp and .h files from the parser folder=20
to the lib-guido2midi folder. A header file should also be created to=20
declare the gd_getTagArgxxx functions: Gmn2MidiParser.h.
This should solve the problem for the library. It has already been=20
tested here. We'll wait for possible objections before committing.

Concerning GuidoCheckForFont and CreateDefaultGDevice, these are=20
obsolete API and we'll remove them from the lib-score-engine files.


>  Finally, the include nview.h contains
> application specific data as well.  It would seem that these
> dependencies need to be removed in order to maintain a truly platform
> dependent and modular score engine.  Perhaps we can discuss some
> strategies?
>

Again, these application specific APIs (AddGGSOutput, AddGuidoOutput)=20
are here for historical reasons, apparently long before the open source=20=

project. Feel free to move them to a more adequate place.

> This also moves towards the next task that Holger, Keith and I will be
> working on - the finalization of a GGS spec, and a move to making that
> the only graphic output of the score engine.

In the current implementation of the graphic engine, the graphic output=20=

and the GGS output are co-existing. All our current developments rely=20
on the graphic output, therefore I'm strongly in favor of maintaining=20
both, as long as they are needed. Moreover, the current abstraction=20
layer over the graphic device dependencies could perhaps be also used=20
for the GGS output; this is just an hypothesis, I don't know the GGS=20
requirements but I think the idea is worth checking.

> It appears now that the
> noteviewer application (through the above mentioned nview.h) is
> assembling the various GGS strings by way of the AddGGSOutput method.
> My thinking is that a new class be written to implement the GGS API
> (when it is finalized), and that it's public API be added to the
> GUIDOEngine.h header, which will be the only public header file
> necessary to work with the library.

That's ok for me.

best
dom

Re: [Guidolib-devel] Code reorganization

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

On Fri, 2004-01-23 at 02:10, Dominique Fober wrote:
> Scott, we apologize for the trouble! We should 
> be more rigorous in making changes that may affect cross-platform 
> development: these changes should be discussed on this list prior to be 
> made. We'll keep it in mind for the future.

That's ok... I actually have a few questions about cross-platform files.

I was doing a bit more testing with the Linux library, and discovered
some problems with the shared library and some unresolved symbols (the
static library works fine because it doesn't require all symbols to be
resolved):

/usr/local/lib/libguidoengine.so: undefined reference to
`gd_getTagArgFloat(int)'
/usr/local/lib/libguidoengine.so: undefined reference to
`gd_getTagArgName(int)'
/usr/local/lib/libguidoengine.so: undefined reference to
`gd_getTagArgType(int)'
/usr/local/lib/libguidoengine.so: undefined reference to
`GuidoCheckForFont(char const*)'
/usr/local/lib/libguidoengine.so: undefined reference to
`CreateDefaultGDevice()'
/usr/local/lib/libguidoengine.so: undefined reference to
`gd_getTagArgInt(int)'
/usr/local/lib/libguidoengine.so: undefined reference to
`gd_getTagArgUnit(int)'
/usr/local/lib/libguidoengine.so: undefined reference to
`gd_getTagArgStr(int)'

I've traced these, and the gd_* functions are referenced in the guido.h
header file (in the parser directory), but are actually defined in the
Gmn2MidiParser.cpp file (in the lib-guido2midi directory).  And the
GuidoCheckForFont and CreateDefaultGDevice are referenced in the
GUIDOEngine.h header file (prior to a platform dependent comment!) and
both are defined in GUIDOMainCarbon.cpp and GUIDOMainWin32.cpp
(depending on platform).  Finally, the include nview.h contains
application specific data as well.  It would seem that these
dependencies need to be removed in order to maintain a truly platform
dependent and modular score engine.  Perhaps we can discuss some
strategies?

This also moves towards the next task that Holger, Keith and I will be
working on - the finalization of a GGS spec, and a move to making that
the only graphic output of the score engine.  It appears now that the
noteviewer application (through the above mentioned nview.h) is
assembling the various GGS strings by way of the AddGGSOutput method. 
My thinking is that a new class be written to implement the GGS API
(when it is finalized), and that it's public API be added to the
GUIDOEngine.h header, which will be the only public header file
necessary to work with the library.  Everyone, please let me know what
your thoughts are on this.  I'll then firm things up with Holger and see
where to go next.  Thanks.

Cheers,

Scott

PS I have improved some of the linux files, and added a few
configuration scripts and an m4 macro to make things easier for other
developers who are using the auto* tools and want to support the engine
library.  The SourceForge developer cvs seems to be down for the
weekend, so I'll have to wait to commit these and account for the files
that got moved.

[Guidolib-devel] Code reorganization

[Dominique F. <fo...@gr...>]

Hi,

Some files included in the lib-score-engine folder have been put in a 
separate folder, namely 'lib-score-engine-add', located at the root of 
the repository. These files are:
GDeviceOpenGL.cpp
GDevicePostScript.cpp
ScoreSymbolMap.cpp
They have been separated from the core library because they represent 
extensions from engine viewpoint and are not necessary for the engine 
operations. This reorganization has been done by Grame a while ago, 
sorry for the delay to announce it.
One of the consequences is that the linux auto tools don't work since 
they assume that a GDevicePostScript.cpp file is present in the 
lib-score-engine folder. Scott, we apologize for the trouble! We should 
be more rigorous in making changes that may affect cross-platform 
development: these changes should be discussed on this list prior to be 
made. We'll keep it in mind for the future.

best
dom

[Guidolib-devel] attachment not received

[<cri...@ti...>]

Dear Jherome,
the mail you sent this morning had no attachment, or I see it as an ascii,
unreadable section to the bottom of the message(possibly because I've set
the mailman "digest" option on? anyway I've just turned it off).
Would you please send it again?
Thank you very much,
Cristiano

Re: [Guidolib-devel] Problems in compiling and running GUIDO NoteViewer for Windows

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

At 20:48 21/01/2004, you wrote:
>Hi everybody,
>first let me apologize in advance: I'm not a C++ developer, and what I'm
>about to say me be very stupid for you. Please, be patient.

Hi Cristiano,
Thank you for reporting this problem. We are happy to help anybody
interested in Guido.


>(1) A few weeks ago I tried to compile some guidolib sources (the
>lib_score_engine.dsp, if I remember well) with Microsoft Visual C++ 5.0
>(it's the one I have, sorry) and I got the errors I've attached to this
>mail.
>
>(2) Yesterday I dowloaded the new released Win 32 GuidoNoteViewer 0.91. When
>I try to run it on my computer (I have Windows 98), I get this error
>message:  "File GUIDOEngine.dll is linked to missing export
>GDI32.dll:SetDCPenColor",
>and the program abort.
>
>Can anybody help?
>Thank you very much.
>
>Cristiano (Bologna, Italy)

In the zip file attached to this mail, you will find a new GUIDOEngine.dll that
should fix the problem (2), and the modified c++ files that could cause the
Visual 5 compile errors. You just have to replace old files with those new
versions.

GUIDOEngine.dll is in the Guido NoteViewer 0.91 application folder.
nvstring.cpp and .h are in the Guido sources: \src\lib-score-engine\

As we do not have neither Windows 98 nor Visual C++  5, I cannot be sure
that the modifications will solve the problems, please let me know if it is the
case or not.

Regards,
Jerome

[Guidolib-devel] Problems in compiling and running GUIDO NoteViewer for Windows

[<cri...@ti...>]

Hi everybody,
first let me apologize in advance: I'm not a C++ developer, and what I'm
about to say me be very stupid for you. Please, be patient.

(1) A few weeks ago I tried to compile some guidolib sources (the
lib_score_engine.dsp, if I remember well) with Microsoft Visual C++ 5.0
(it's the one I have, sorry) and I got the errors I've attached to this
mail.

(2) Yesterday I dowloaded the new released Win 32 GuidoNoteViewer 0.91. When
I try to run it on my computer (I have Windows 98), I get this error
message:  "File GUIDOEngine.dll is linked to missing export
GDI32.dll:SetDCPenColor",
and the program abort.

Can anybody help?
Thank you very much.

Cristiano (Bologna, Italy)


----- Original Message -----
From: <gui...@li...>
To: <gui...@li...>
Sent: Wednesday, January 21, 2004 5:01 AM
Subject: Guidolib-devel digest, Vol 1 #22 - 1 msg


> Send Guidolib-devel mailing list submissions to
> gui...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/guidolib-devel
> or, via email, send a message with subject or body 'help' to
> gui...@li...
>
> You can reach the person managing the list at
> gui...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Guidolib-devel digest..."
>
>
> Today's Topics:
>
>    1. GUIDO Music Notation newsletter (Jerome Berthet)
>
> --__--__--
>
> Message: 1
> Date: Tue, 20 Jan 2004 13:01:30 +0100
> To: gui...@li...
> From: Jerome Berthet <be...@gr...>
> Subject: [Guidolib-devel] GUIDO Music Notation newsletter
>
> ====================================================
>      G U I D O  Music Notation news
>      January 19, 2004
>
>      <http://sourceforge.net/projects/guidolib/>
> ====================================================
>
>
> * New version 1.2 of the Guido Engine library has been released.
>    This version fixes some bugs, compiles faster, includes new entry
> points and is fully cross-platform. Sources are cleaner and documented
> using doxygen.
>
>
> * Binary viewer applications have been released on sourceforge. They
> embed the new version of the Guido Engine library.
>
>
>      - (MacOS-X) GuidoViewer 0.1.1: supports multiple documents and
>         printing. It uses Quartz to render musical scores.
>
>
>      - (Windows) GuidoNoteViewer 0.91: minor changes, updated gif
>          export.
>
>
> * Linux branch of the Guido Engine library now use the standard
>      auto* tools (GNU build system).
>
>
> * The CVS dev branch has been merged to the main branch.
>
>
>
>
>
> --__--__--
>
> _______________________________________________
> Guidolib-devel mailing list
> Gui...@li...
> https://lists.sourceforge.net/lists/listinfo/guidolib-devel
>
>
> End of Guidolib-devel Digest