Am 16. September 2016 02:37:53 MESZ, schrieb Paul <p...@paulwmorris.com>: >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. >
First of all, I think this is a good idea, and it comes at a good moment, shortly before I/we start fiddling around with new uses for the ID in for example going after graphical editing features. >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. Doesn't a conversion to #`(id . ,(existing-function)) suffice? Otherwise just follow Carl's suggestion. Best Urs > >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 -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
