On 2016/08/23 19:43:14, dak wrote:
On 2016/08/21 16:23:57, http://mark_opus11.net wrote:
> On 2016/08/21 16:22:14, http://mark_opus11.net wrote:
> > Group lower-level contexts
>
> This introduces a `VerticalAxisGroup.keep-alive-group'
> property which can be set to a symbol to associate a
> subset of contexts under the control of the same
> Keep_alive_together_engraver. This group can further be
> set to operate only up to a maximum layer level with the
> `keep-alive-group-layer' property.
Well, this doesn't seem to do more than the
removal-friends/removal-foes proposal (or does it?) and
complicates things thoroughly.
True, although it does it via an interface which is more
closely related to the structure of the score and easier to
understand (IMO).
We create a new context, say RemovalGroup. It has no
engravers apart from the Keep_alive_together_engraver.
And the Keep_alive_together_engraver does not descend into
contexts already having a Keep_alive_together_engraver,
instead letting _that_ Keep_alive_together_engraver make
its decisions and, uh, consider itself alive if any of its
subcontexts is alive? That way its layer number could be
assigned independently from the layer numbers of its
subcontexts, making it possible not to have to keep a
global tally of subgroups but rather use group numbers
fresh at each layer. Which would greatly facilitate
providing context mods for assigning all the layer numbers
and stuff as they would not need to take into account
lower or higher groupings.
Yes, I considered this also, but...
This would sound _almost_ as powerful as your plan and
considerably simpler in use. The downside is that if you
wanted to have a group with non-contiguous elements, you'd
have to put them contiguous into the source and juggle
with alignBelowContext and alignAboveContext for
rearranging them. But is that a common use case?
... it is specifically one of the use cases that was raised
on the list (which led me to the keep-alive-group proposal).
Unfortunately in these cases alignAboveContext /
alignBelowContext don't work to rearrange non-contiguous
contexts into potentially non-existent system-start-braces.
So I think that having non-contiguous sub-groups is pretty
much vital to the usefulness of the feature.
I agree that the `keep-alive-group-layer` property is not
particularly elegant, and somewhat redundant as it is just
max(remove-layer for layers in group). These values could be
found automatically by adding a loop through the Grobs to
populate a map of (group-name, max-remove-layer-values)
before the main loop. I didn't bother doing this until the
concept was worked out.
I hope not, but I might be overlooking something in the
context of lyrics.
Actually in the process of working on Kieren's example I did
find some issues involving Lyrics. Everything works, but
things do become rather verbose due to the need to specify
\overrides for each Lyrics context. Perhaps I'm missing
something here, but it seems an explicitly created Lyrics
context requires a named voice to align to using \lyricsto -
this is difficult to specify when using e.g. \partcombine to
create a staff.
A thought of how to deal with this would be to have a
remove-layer symbol value #'above, which would keep the
context alive with, and only with, the context above it.
This could then be applied in a global layout block to all
Lyrics contexts. It could be also useful for Dynamics and
similar supplementary contexts. Perhaps #'below could be
defined also for symmetry. Implementation is essentially:
if (scm_is_eq (this_layer, ly_symbol2scm ('above') and
i == j + 1))
So, a proposal: The keep-alive-group stuff should in any
case be separated into another patch and discussed further.
I suggest returning to Patch Set 2, as described in
Comment #8, with the addition of the #'above symbol, as a
first step.
https://codereview.appspot.com/308910043/
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
