Re: Create engravers for merging rests (issue 321930043 by horndud...@gmail.com)
One nit. See below. No need for a new patch-set, imho. You could change it right before pushing. Otherwise LGTM https://codereview.appspot.com/321930043/diff/160001/Documentation/notation/simultaneous.itely File Documentation/notation/simultaneous.itely (right): https://codereview.appspot.com/321930043/diff/160001/Documentation/notation/simultaneous.itely#newcode917 Documentation/notation/simultaneous.itely:917: parts. This can be accomplished using the merge rests engraver. I'd use the name, i.e. "Merge_rests_engraver" https://codereview.appspot.com/321930043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Create engravers for merging rests (issue 321930043 by horndud...@gmail.com)
https://codereview.appspot.com/321930043/diff/160001/Documentation/notation/simultaneous.itely
File Documentation/notation/simultaneous.itely (right):
https://codereview.appspot.com/321930043/diff/160001/Documentation/notation/simultaneous.itely#newcode917
Documentation/notation/simultaneous.itely:917: parts. This can be
accomplished using the merge rests engraver.
On 2017/06/12 07:40:42, thomasmorley651 wrote:
I'd use the name, i.e. "Merge_rests_engraver"
In that case I'd write
using @code{Merge_rests_engraver}
namely omitting "the".
https://codereview.appspot.com/321930043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-manuals.css: edit color scheme and some spacing (issue 322070043 by paulwmor...@gmail.com)
I like a lot the new color scheme! More elegant and easier for the eyes. https://codereview.appspot.com/322070043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Initial work to support opentype font features (issue 323850043 by horndud...@gmail.com)
On 2017/06/05 05:01:28, horndude77 wrote: Update minimum pango version If I understand correctly, LilyDev 4.1 cannot compile this patch. In my humble opinion, it is necessary that LilyDev 4.1 can compile it. I want to hear the opinions of LilyDev 4.1 users. If it is necessary, shall I create an additional patch that can be compiled by LilyDev 4.1? Jay, would you send us the git format-patch file? Then, I can commit your patch my the additional patch. https://codereview.appspot.com/323850043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add on-page-greater-than, -less-than (on-the-fly) (issue 74540044)
On 2017/06/10 19:36:30, pwm wrote:
That's a nice consistency. I tried it out and the following works
too:
#(define (onpage proc nmbr)
(markup-when ((page:page-number -1))
(proc page:page-number nmbr)))
\paper {
#(set-paper-size "a7landscape")
oddFooterMarkup = \markup \on-the-fly #(onpage > 3) "This is
long!"
}
Come to think of it, the only application would seem in connection with
\on-the-fly, so it should be possible to wrap the \on-the-fly invocation
into the macro as well.
I've put up issue 5145 for basically replacing \on-the-fly with $ when
one really wants to write this as \markup $(onpage > 3) "This is long!".
This requires an amended definition of markup-when adding a markup
command signature:
#(define-macro (markup-when properties . cond)
`(let ((markfun
(lambda (layout props arg)
(if
(let ,(map (lambda (p)
(if (pair? p)
`(,(car p) (chain-assoc-get ',(car p) props
,@(cdr p)))
`(,p (chain-assoc-get ',p props
properties)
,@cond)
(interpret-markup layout props arg)
empty-stencil
(set! (markup-command-signature markfun)
(list markup?))
markfun))
#(define (on-page-greater-than nmbr)
(markup-when ((page:page-number -1))
(> page:page-number nmbr)))
\paper {
#(set-paper-size "a7landscape")
oddFooterMarkup = \markup $(on-page-greater-than 3) "This is long!"
}
\score {
\repeat unfold 256 c'1
}
I don't actually want to pursue this path as the preferred user
interface: it just seemed to me that it should work.
https://codereview.appspot.com/74540044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-manuals.css: edit color scheme and some spacing (issue 322070043 by paulwmor...@gmail.com)
On 06/10/2017 07:30 PM, carl.d.soren...@gmail.com wrote: I don't feel strongly about the old design being bad. What got me motivated to work on it was the bright (fully saturated) colored borders around the code blocks, which I found distracting. The new design looks mostly fine to me. Glad to hear it. I feel like the table of contents bar at the left is too wide. I agree; it can get a bit wide especially on wider monitors/windows. (Note I have not changed its width in this patch.) Currently the size is a percentage of the window width. We could make that smaller, but at the risk that it gets too narrow on smaller screens/windows. Another way would involve a different approach in the css, allowing us to set a maximum and minimum width to it. But this would entail more work/changes to the css and maybe the html. (e.g. to use floats, flexbox, or grid positioning rather than the current "position: fixed;" approach.) Or... we could keep the "position: fixed;" approach and set the width to a constant amount rather than a percentage. And/or we could also set media query break points to change that constant for different window widths. This could even be combined with the percentages so it could effectively have a max and min width and be set by percent in between. In any case this would warrant its own issue. But I would be fine with it being like this. Glad to hear, and thanks for the feedback. -Paul ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-manuals.css: edit color scheme and some spacing
> > I feel like the table of contents bar at the left is too wide. >> > > I agree; it can get a bit wide especially on wider monitors/windows. > (Note I have not changed its width in this patch.) Currently the size is a > percentage of the window width. We could make that smaller, but at the > risk that it gets too narrow on smaller screens/windows. > > Another way would involve a different approach in the css, allowing us to > set a maximum and minimum width to it. But this would entail more > work/changes to the css and maybe the html. (e.g. to use floats, flexbox, > or grid positioning rather than the current "position: fixed;" approach.) > > Or... we could keep the "position: fixed;" approach and set the width to a > constant amount rather than a percentage. And/or we could also set media > query break points to change that constant for different window widths. > This could even be combined with the percentages so it could effectively > have a max and min width and be set by percent in between. > > In any case this would warrant its own issue. > > But I would be fine with it being like this. >> > > Glad to hear, and thanks for the feedback. > > -Paul > CSS is happy with both properties set: width as a percentage and min-width as an absolute value. There is no conflict and they should work together well. David Elaine Alt 415 . 341 .4954 "*Confusion is highly underrated*" ela...@flaminghakama.com self-immolation.info skype: flaming_hakama Producer ~ Composer ~ Instrumentalist -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-manuals.css: edit color scheme and some spacing
On 06/12/2017 03:02 PM, Flaming Hakama by Elaine wrote: CSS is happy with both properties set: width as a percentage and min-width as an absolute value. There is no conflict and they should work together well. Hi, yes, thanks, but... I glossed over the details. If you look at the css file you'll find that the main content div is positioned so that its "left" property is a percentage that corresponds with the sidebar's "right" property. There is actually no "width" property in use and I don't think there is a maximum left/right css property to use, thus... what I wrote in my previous email. -Paul ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-manuals.css: edit color scheme and some spacing (issue 322070043 by paulwmor...@gmail.com)
On 06/12/2017 06:24 AM, fedel...@gmail.com wrote: I like a lot the new color scheme! More elegant and easier for the eyes. Thanks, glad you like it! ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
regression introduced with issue 5122 "Fix not scaling stem in note-by-number-markup"
As of https://sourceforge.net/p/testlilyissues/issues/5122/#99dc commit eee677c480c78d58a5215e246575aa94ba2d1897 introduced a regression. Not sure when I have the time to look deeper into it. At first sight I've no good idea for a proper fix. So I suggest to revert it. At least it should not go into 2.20 in the current state. Cheers, Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
