Nice! This definitely solves the basic problem nicely.
Lukas sent me [off-list] a totally different solution that was also
excellent.
Maybe we can/should discuss the pros and cons of each approach — and
others, if they’re offered — with an eye to eventually submitting a
patch…?
I don't know what Lukas proposed. For a new feature
added to LilyPond proper, I don't see a way around
the good old methods: define two new grobs and an
engraver to create them.
Well, the code I sent Kieren off-list was more-or-less equivalent to
what Harm provided: We both had the same cruel idea of hijacking the
Y-offset calculation using a procedure that changes the stencil as a
side-effect. (Probably we were both inspired by the fact that the
necessary computations of the StaffGroup's total Y extent are contained
in system-start-text::calc-y-offset, the standard callback for
InstrumentName.Y-offset.)
We also both did not bother try to do the horizontal alignment the right
way.
Here are some thoughts on the subject:
- I'm not sure if "staff-group names with brackets" should be done as a
new Layout object / by a new engraver, or if this should be added to the
functionality of InstrumentName and the Instrument_name_engraver.
Conceptually, I was never really happy with the staff group names being
called InstrumentName's, but I have to admit it's convenient, and for
reasons of backwards compatibility, it should probably stay that way.
- The ability to deal with the needs of multi-staff groups specifically
might make it reasonable to create a dedicated engraver
(Group_name_engraver?) that mimicks and extends the
Instrument_name_engraver. The context definitions of StaffGroups etc.
then could be changed such that only Staff (and TabStaff etc.) contexts
\consist the standard Instrument_name_engraver, whereas the grouping
contexts should have the Group_name_engraver.
- Grouping staves visually by a bracketed instrument name means that it
might be reasonable not to have SystemStartBracket's etc. for the same
group. I think this is a good opportunity to add something I've wanted
for a long time, namely a staff grouping context that provides _only_
logical grouping and has no hardwired visual grouping elements (SpanBar,
SystemStartBracket etc.), and from which StaffGroup and all the other
contexts should be derived. Maybe StaffCollection would be a suitable name?
- Vertical ("rotated") printing of the Group Name should be available as
a boolean option, not depend on manual markup rotation.
- The hard part seems to be horizontal spacing. Two layout options come
to mind which should both be supported: Staff names on the inside ("on
the right"), group name with bracket on the outside ("on the left"); and
vice versa: group name with bracket on the inside ("on the right"), and
single staff names on the outside ("on the left"). These pose different
layout problems: For the first option, the machinery creating the
GroupName has to know the extents of all the single-staff
InstrumentNames. For the second option, the GroupName machinery has to
increase the padding for the single staff names. I'm not clear yet if
this requires a separate implementation of the two options.
- The first option wished for by Adam (horizontal alignment of all the
brackets) is very easy to implement; this is just a matter of fixed
paddings.
As Harm already stated that he won't have time to work on this for now,
I'd be happy to try my hands on this a bit.
Lukas
