Hi all, I'd like to improve on the "id" grob property but I wanted to
ask about the best way to migrate users if/when we made the change I'm
thinking of.
The "id" property was introduced [0] in January 2012 by commit:
ad3a9e6531e32c4403f1bdc6d203d3c94c6d411e
Adds an ID property to grobs.
This property is intended to group visual elements of a grob in a given
backend into a container that has `id' as its id. Currently, it is only
implemented for svg, where grobs are wrapped in a <g> tag with its `id'
attribute set to `id.'
As far as I can tell that's still all it does. I'd like to change its
type from a string to an alist (well, "list?") and change its name to
something like "output-properties". And make it so users could do
things like:
\override NoteHead.output-properties =
#'((id . 324) (class . "bar") (data-custom-prop . "foo"))
Which would produce in the SVG output:
<g id="324" class="bar" data-custom-prop="foo"> ... </g>
(The SVG spec allows arbitrary custom properties that start with "data-".)
Looking at the code, the changes seem pretty straightforward to do.
Assuming we agree this is a good improvement to make, the question I
have is about migrating existing user files to the new property.
Literal strings are easy enough to handle with convert-ly: = "abc"
converts to = #'((id . "abc"))
The problem is when users have assigned a procedure (that returns a
string) to this property, which is surely a common use case. I don't
see a reasonable way to handle that with convert-ly. Maybe it is
possible but seems like it would get ugly.
So we could make the new property's type be "string-or-list?". (We'd
have to define that predicate.) Then for strings, output a deprecation
warning, but go ahead and handle the string as the user expects. That
would give users time to rewrite their code and then at some future
point we change the type to just "list?" and only support alist values.
Is anyone opposed to this migration strategy? Any better options I'm
missing?
The motivation for the change is that lilypond-html-live-score[1] is
overloading the id string with multiple properties and then
post-processing that string (in the SVG output file) with python to
expand it into different properties. But I see no reason why LilyPond
shouldn't be able to do this directly, saving the post-processing step.
And it would generally increase the possible uses for SVG output.
(I considered introducing a separate property, but especially after
looking at the code, it seems best to redefine the current one.)
(I suppose another option would be to just allow string values (which
would be output as the id) in addition to alist values, but I'm not sure
whether that would be best in the long run.)
Thanks,
-Paul
[0]
http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=ad3a9e6531e32c4403f1bdc6d203d3c94c6d411e
[1] https://gitlab.com/sigmate/lilypond-html-live-score
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
