Re: Doc: NR - 2.10 World Music Turkish Classical additions (issue 550780043 by pkxgnugi...@runbox.com)
Reviewers: lemzwerg,
https://codereview.appspot.com/550780043/diff/560710043/Documentation/notation/world.itely
File Documentation/notation/world.itely (right):
https://codereview.appspot.com/550780043/diff/560710043/Documentation/notation/world.itely#newcode74
Documentation/notation/world.itely:74: Western staff notes are still
used, but with special accidentals unique
On 2019/05/31 07:05:12, lemzwerg wrote:
unique → uniquely
Done.
https://codereview.appspot.com/550780043/diff/560710043/Documentation/notation/world.itely#newcode78
Documentation/notation/world.itely:78: Other, related, init files are
also available; @file{hel-arabic.ly} and
On 2019/05/31 07:05:12, lemzwerg wrote:
Other, related, init files → Other, related init files
Done.
https://codereview.appspot.com/550780043/diff/560710043/Documentation/notation/world.itely#newcode438
Documentation/notation/world.itely:438: @q{group} of maqams than
individual key signatures for each maqam
On 2019/05/31 07:05:12, lemzwerg wrote:
than → instead of
Done.
https://codereview.appspot.com/550780043/diff/560710043/Documentation/notation/world.itely#newcode439
Documentation/notation/world.itely:439: seperately.
On 2019/05/31 07:05:12, lemzwerg wrote:
seperately → separately
Done.
https://codereview.appspot.com/550780043/diff/560710043/Documentation/notation/world.itely#newcode505
Documentation/notation/world.itely:505: of a tone, from which are
constructed the melodic forms known as
On 2019/05/31 07:05:12, lemzwerg wrote:
from which the melodic forms ... are constructed.
Done.
https://codereview.appspot.com/550780043/diff/560710043/Documentation/notation/world.itely#newcode521
Documentation/notation/world.itely:521: the basis of pitch on 1/9-tone
divisions means makamlar employ a
On 2019/05/31 07:05:12, lemzwerg wrote:
means → means that
Done.
https://codereview.appspot.com/550780043/diff/560710043/Documentation/notation/world.itely#newcode522
Documentation/notation/world.itely:522: completely different set of
intervals from Western scales and modes:
On 2019/05/31 07:05:12, lemzwerg wrote:
from → compared to
Done.
https://codereview.appspot.com/550780043/diff/560710043/Documentation/notation/world.itely#newcode560
Documentation/notation/world.itely:560: The correct accidentals koma
flat (@var{b1}) and koma sharp (@code{f4}),
On 2019/05/31 07:05:12, lemzwerg wrote:
accidentals, ... (...), ...
Done.
https://codereview.appspot.com/550780043/diff/560710043/Documentation/notation/world.itely#newcode591
Documentation/notation/world.itely:591: contains information in English
regarding Turkish makam including 2 CDs.
On 2019/05/31 07:05:12, lemzwerg wrote:
2 → two
Done.
https://codereview.appspot.com/550780043/diff/560710043/Documentation/snippets/new/turkish-makam-example.ly
File Documentation/snippets/new/turkish-makam-example.ly (right):
https://codereview.appspot.com/550780043/diff/560710043/Documentation/snippets/new/turkish-makam-example.ly#newcode7
Documentation/snippets/new/turkish-makam-example.ly:7: Here is a
template that also uses the start of a well known Turkish
On 2019/05/31 07:05:12, lemzwerg wrote:
Here is a template that also uses... → This template uses...
well known → well-known
Done.
Description:
Doc: NR - 2.10 World Music Turkish Classical additions
Additions to Turkish Classical Music
From suggestions made by Adam Good
also references to Adam's recent
Turkish Makam additions.
Removed @lilypond example and
made it a snippet.
Formatted changed sections so
they follow more closely to the
CG Guidelines.
Removed the table listing some
of the modes and referenced the
Turkish Makam ly file instead as
it has significantly more additions.
Please review this at https://codereview.appspot.com/550780043/
Affected files (+164, -125 lines):
M Documentation/notation/world.itely
A Documentation/snippets/new/turkish-makam-example.ly
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add glib-2.0 and gobject-2.0 library dependency (issue 552770043 by pkxgnugi...@runbox.com)
Reviewers: lemzwerg, https://codereview.appspot.com/552770043/diff/574790043/aclocal.m4 File aclocal.m4 (right): https://codereview.appspot.com/552770043/diff/574790043/aclocal.m4#newcode1291 aclocal.m4:1291: save_CPPFLAGS="$CPPFLAGS" On 2019/06/04 05:40:35, lemzwerg wrote: we probably should replace tabs with spaces ... Done. https://codereview.appspot.com/552770043/diff/574790043/config.make.in File config.make.in (right): https://codereview.appspot.com/552770043/diff/574790043/config.make.in#newcode23 config.make.in:23: CONFIG_CFLAGS = @CFLAGS@ $(GLIB_CFLAGS)$(GUILE_CFLAGS) $(FREETYPE2_CFLAGS) $(PANGO_FT2_CFLAGS) On 2019/06/04 05:40:35, lemzwerg wrote: A space is missing here. Done. Description: Add glib-2.0 and gobject-2.0 library dependency For a long time we relied on pango/pangoft2 to pull in the glib and gobject libraries. That worked as long as every distribution used a pangoft2.pc file that included both libs in the 'Required:' line. According to the pkg-config documentation that was definitely wrong, and the problem was corrected on opensuse tumbleweed recently. As a consequence building lilypond failed with a linker error as we use symbols from both libs directly in our c++ source code. Signed-off-by: Knut Petersen Please review this at https://codereview.appspot.com/552770043/ Affected files (+44, -2 lines): M aclocal.m4 M config.make.in M configure.ac Index: aclocal.m4 diff --git a/aclocal.m4 b/aclocal.m4 index cf558c81e91ce044dd7a642038e92bbc40836d77..cb4fa83414af72d6d8b3d23611cab4269845121a 100644 --- a/aclocal.m4 +++ b/aclocal.m4 @@ -1284,6 +1284,44 @@ AC_DEFUN(PKG_CHECK_MODULES, [ fi ]) +AC_DEFUN(STEPMAKE_GLIB, [ +PKG_CHECK_MODULES(GLIB, $1 >= $3, have_glib=yes, true) +if test "$have_glib" = yes; then + AC_DEFINE(HAVE_GLIB) +save_CPPFLAGS="$CPPFLAGS" +save_LIBS="$LIBS" + CPPFLAGS="$GLIB_CFLAGS $CPPFLAGS" + LIBS="$GLIB_LIBS $LIBS" + AC_SUBST(GLIB_CFLAGS) + AC_SUBST(GLIB_LIBS) + CPPFLAGS="$save_CPPFLAGS" + LIBS="$save_LIBS" +else + r="libglib-dev or glib?-devel" + ver="`pkg-config --modversion $1`" + STEPMAKE_ADD_ENTRY($2, ["$r >= $3 (installed: $ver)"]) +fi +]) + +AC_DEFUN(STEPMAKE_GOBJECT, [ +PKG_CHECK_MODULES(GOBJECT, $1 >= $3, have_gobject=yes, true) +if test "$have_gobject" = yes; then + AC_DEFINE(HAVE_GOBJECT) +save_CPPFLAGS="$CPPFLAGS" +save_LIBS="$LIBS" + CPPFLAGS="$GOBJECT_CFLAGS $CPPFLAGS" + LIBS="$GOBJECT_LIBS $LIBS" + AC_SUBST(GOBJECT_CFLAGS) + AC_SUBST(GOBJECT_LIBS) + CPPFLAGS="$save_CPPFLAGS" + LIBS="$save_LIBS" +else + r="libgobject-dev or gobject?-devel" + ver="`pkg-config --modversion $1`" + STEPMAKE_ADD_ENTRY($2, ["$r >= $3 (installed: $ver)"]) +fi +]) + AC_DEFUN(STEPMAKE_FREETYPE2, [ PKG_CHECK_MODULES(FREETYPE2, $1 >= $3, have_freetype2=yes, true) if test "$have_freetype2" = yes; then Index: config.make.in diff --git a/config.make.in b/config.make.in index 420600ae8e5327a676be2940362e457ba6b6c3ce..c9e1d992daae26ab7823b66169c7b7fb35c882b2 100644 --- a/config.make.in +++ b/config.make.in @@ -15,11 +15,12 @@ FREETYPE2_CFLAGS = @FREETYPE2_CFLAGS@ GUILE_CFLAGS = @GUILE_CFLAGS@ PANGO_FT2_CFLAGS = @PANGO_FT2_CFLAGS@ PYTHON_CFLAGS = @PYTHON_CFLAGS@ +GLIB_CLFAGS = @GLIB_CFLAGS@ @GOBJECT_CFLAGS@ CONFIG_CPPFLAGS = @CPPFLAGS@ CONFIG_DEFINES = @DEFINES@ -CONFIG_CFLAGS = @CFLAGS@ $(GUILE_CFLAGS) $(FREETYPE2_CFLAGS) $(PANGO_FT2_CFLAGS) +CONFIG_CFLAGS = @CFLAGS@ $(GLIB_CFLAGS)$(GUILE_CFLAGS) $(FREETYPE2_CFLAGS) $(PANGO_FT2_CFLAGS) CONFIG_CXXFLAGS = @CXXFLAGS@ $(GUILE_CFLAGS) $(FREETYPE2_CFLAGS) $(PANGO_FT2_CFLAGS) FONTCONFIG_LIBS = @FONTCONFIG_LIBS@ @@ -28,8 +29,9 @@ FREETYPE2_LIBS = @FREETYPE2_LIBS@ PANGO_FT2_LIBS = @PANGO_FT2_LIBS@ PYTHON_LIBS = @PYTHON_LDFLAGS@ CXXABI_LIBS = @CXXABI_LIBS@ +GLIB_LIBS = @GLIB_LIBS@ @GOBJECT_LIBS@ -CONFIG_LIBS = @LIBS@ @EXTRA_LIBS@ $(GUILE_LIBS) $(PANGO_FT2_LIBS) $(FONTCONFIG_LIBS) $(FREETYPE2_LIBS) +CONFIG_LIBS = @LIBS@ @EXTRA_LIBS@ $(GLIB_LIBS) $(GUILE_LIBS) $(PANGO_FT2_LIBS) $(FONTCONFIG_LIBS) $(FREETYPE2_LIBS) CONFIG_LDFLAGS = @LDFLAGS@ PACKAGE = @PACKAGE@ Index: configure.ac diff --git a/configure.ac b/configure.ac index e53bfcc4d6d7f3c3d1bc374f27dea876c3410739..bd1db31bddd4f375c29b01e8a374fca4d54b0e1a 100644 --- a/configure.ac +++ b/configure.ac @@ -283,6 +283,8 @@ if test "$have_pangoft2_with_otf_feature" != yes ; then fi STEPMAKE_FONTCONFIG(fontconfig, REQUIRED, 2.4.0) STEPMAKE_FREETYPE2(freetype2, REQUIRED, 2.1.10) +STEPMAKE_GLIB(glib-2.0, REQUIRED,2.44) +STEPMAKE_GOBJECT(gobject-2.0, REQUIRED,2.44) STEPMAKE_WINDOWS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New function css-color (accompanying x11-color) (issue 570690043 by g...@ursliska.de)
Am 04.06.19 um 10:53 schrieb Urs Liska: Am 04.06.19 um 00:13 schrieb thomasmorle...@gmail.com: https://codereview.appspot.com/570690043/diff/564820043/scm/color.scm File scm/color.scm (right): https://codereview.appspot.com/570690043/diff/564820043/scm/color.scm#newcode678 scm/color.scm:678: (define css-color-list Is there anything new in this list or are all entries always alias? I checked and saw that the following CSS colors are *not* in the X11 list: CSS Color names not defined in X11 colors: ... *Most* of the others are basically defined identical, with the differences being rounding errors. However, there are a number of real differences, AFAICS it's the discrepancies described in https://en.wikipedia.org/wiki/X11_color_names#Clashes_between_web_and_X11_colors_in_the_CSS_color_scheme The proper list of differenlty defined colors is: CSS Color names not defined in X11 colors: aqua crimson fuchsia indigo lime olive rebeccapurple silver teal CSS Color defined differently than X11: gray green grey maroon purple ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New function css-color (accompanying x11-color) (issue 570690043 by g...@ursliska.de)
Am 04.06.19 um 00:13 schrieb thomasmorle...@gmail.com: https://codereview.appspot.com/570690043/diff/564820043/scm/color.scm File scm/color.scm (right): https://codereview.appspot.com/570690043/diff/564820043/scm/color.scm#newcode678 scm/color.scm:678: (define css-color-list Is there anything new in this list or are all entries always alias? I checked and saw that the following CSS colors are *not* in the X11 list: CSS Color names not defined in X11 colors: aqua crimson fuchsia indigo lime olive rebeccapurple silver teal *Most* of the others are basically defined identical, with the differences being rounding errors. However, there are a number of real differences, AFAICS it's the discrepancies described in https://en.wikipedia.org/wiki/X11_color_names#Clashes_between_web_and_X11_colors_in_the_CSS_color_scheme ... Ofcourse this leads to identical definitions for css-color and x11-color and x11-color would return a color even for p.e. Darkblue (wrongly cased). I can't imagine a problem, though I'm not totally sure about the best way to proceed here. I agree that it's not a terrific idea to duplicate all those color definitions. However, especially given the number of differences there should be explicit access methods for both color models. What might be a reasonable approach is: * Have one long list of shared color definitions, basically the existing one plus entries for the list above (I assume we can ignore the rounding errors issue) * For each color model have a list of *names* and a list (doesn't have to be a *separate* list) of definitions for colors that don't match the shared-colors list. For X11 this would *only* be the names list. (The determination of colors that need special definitions should be done once during development, not at runtime.) * When asking for a color it is first checked if it is in the color model's extension list, then in the shared list (and then fall back to black) * Given that the X11 colors Wikipedia entry states that the capitalization of X11 color names isn't handled consistently I suggest that we totally ignore casing (keep the CamelCase names in the manual but state that colors can be requested case insensitively) What do you think? Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
