Re: Proposal: change Grob.id to Grob.output-properties

[Urs Liska]

Am 16. September 2016 02:37:53 MESZ, schrieb Paul <address@hidden>:
>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
>address@hidden
>https://lists.gnu.org/mailman/listinfo/lilypond-devel

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.