Re: Add output-attributes grob property to replace id (issue 308430043 by paulwmor...@gmail.com)
https://codereview.appspot.com/308430043/diff/1/python/convertrules.py File python/convertrules.py (right): https://codereview.appspot.com/308430043/diff/1/python/convertrules.py#newcode3906 python/convertrules.py:3906: @rule ((2, 19, 49), r"""\override ... .id = "a-string" -> Any reason we just don't keep the id? And if not, why override all of output-attributes instead of just output-attributes.id ? And what's with tweaks? And/or overrideProperty? https://codereview.appspot.com/308430043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add output-attributes grob property to replace id (issue 308430043 by paulwmor...@gmail.com)
On 2016/09/27 10:06:26, dak wrote: https://codereview.appspot.com/308430043/diff/1/python/convertrules.py File python/convertrules.py (right): https://codereview.appspot.com/308430043/diff/1/python/convertrules.py#newcode3906 python/convertrules.py:3906: @rule ((2, 19, 49), r"""\override ... .id = "a-string" -> Any reason we just don't keep the id? I considered this, but it's simpler for both code and user if all these svg output attributes are in the same alist property rather than split across two. Currently the id property is not used for anything else, so no need to keep it around. Later if another (e.g. internal) use for a grob id property arises, we could add it back then. And if not, why override all of output-attributes instead of just output-attributes.id ? Good call, that would be better (not to mention easier to do with the convert rule). And what's with tweaks? And/or overrideProperty? Oops, that's an oversight. I'll do another patch set. Thanks for the review, -Paul https://codereview.appspot.com/308430043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add output-attributes grob property to replace id (issue 308430043 by paulwmor...@gmail.com)
Am 27.09.2016 um 20:46 schrieb paulwmor...@gmail.com: > I considered this, but it's simpler for both code and user if all these > svg output attributes are in the same alist property rather than split > across two. Currently the id property is not used for anything else, so > no need to keep it around. Later if another (e.g. internal) use for a > grob id property arises, we could add it back then. We will definitely want to have an 'id property to address elements from elsewhere in a document, be it spanners or be it edition-engraver mods or similar additions. Maybe in the context of partial recompilation features IDs may become handy. So it might be an option to leave a top-level 'id property in place right now instead of possibly adding it back at a later point? Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add output-attributes grob property to replace id (issue 308430043 by paulwmor...@gmail.com)
On 09/27/2016 02:49 PM, Urs Liska wrote: We will definitely want to have an 'id property to address elements from elsewhere in a document, be it spanners or be it edition-engraver mods or similar additions. Maybe in the context of partial recompilation features IDs may become handy. So it might be an option to leave a top-level 'id property in place right now instead of possibly adding it back at a later point? Ok, since there's hesitation about removing it, I'll leave it in. We can always remove it in a follow-up patch if that is desired. I will keep the convert-ly rule that rewrites ".id" to ".output-attributes.id" to help keep the svg functionality working for existing user files. For the doc string I'll just use "An id string for the grob." I'm open to suggestions if anyone thinks it should say more, like "not currently used by LilyPond". (This brings up some thoughts I've had about supporting custom properties. I'll send another email about that.) -Paul ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Proposal: support for custom grob and context properties
Hi all, It would be nice if LilyPond supported user-defined grob and context properties, for use in users' code -- in the spirit of practical software freedom and to further LilyPond's excellent extensibility. It would also be handy for prototyping code that might end up in LilyPond. Harm recently used custom properties in his BendSpanner-engraver, and I use them in my code for alternative notation systems. Currently this requires finding and copy/pasting the relevant scheme procedures so they can be used in your own files. Namely, define-grob-property from scm/define-grob-properties.scm and translator-property-description from scm/define-context-properties.scm. Here are two possibilities for making this easier: 1. Make those two procedures "define-public" so users can just use them to define their own properties. This requires very minimal change to LilyPond code, and is convenient for users since existing functions will just work for accessing and setting their custom properties (e.g. ly:grob-property). 2. Define a "custom-properties" grob property and a "customProperties" context property (or whatever name) that each holds an alist of user properties. This adds additional properties to LilyPond and is a little more complex for the user to work with, but it provides isolation from LilyPond's properties. (For example, users would only have to worry about conflicts with other user-defined properties, not conflicts with current or future LilyPond properties.) I'm interested in implementing this one way or another. Using the same approach for grob and context properties would make sense. Thoughts? -Paul ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Proposal: support for custom grob and context properties
Paul writes: > Hi all, > > It would be nice if LilyPond supported user-defined grob and context > properties, for use in users' code -- in the spirit of practical > software freedom and to further LilyPond's excellent extensibility. It > would also be handy for prototyping code that might end up in > LilyPond. > > Harm recently used custom properties in his BendSpanner-engraver, and > I use them in my code for alternative notation systems. > > Currently this requires finding and copy/pasting the relevant scheme > procedures so they can be used in your own files. Namely, > define-grob-property from scm/define-grob-properties.scm and > translator-property-description from > scm/define-context-properties.scm. > > Here are two possibilities for making this easier: > > 1. Make those two procedures "define-public" so users can just use > them to define their own properties. This requires very minimal > change to LilyPond code, and is convenient for users since existing > functions will just work for accessing and setting their custom > properties (e.g. ly:grob-property). The problem with the current implementation is that such additions are not limited in scope and will persist beyond the currently processed file. > 2. Define a "custom-properties" grob property and a "customProperties" > context property (or whatever name) that each holds an alist of user > properties. This adds additional properties to LilyPond and is a > little more complex for the user to work with, but it provides > isolation from LilyPond's properties. (For example, users would only > have to worry about conflicts with other user-defined properties, not > conflicts with current or future LilyPond properties.) This will not work with current code checks working with object properties. > I'm interested in implementing this one way or another. Using the > same approach for grob and context properties would make sense. > > Thoughts? First you'd need to move is-grob? and its friends from the old "object properties" interface to the new, function-calling one. That's an incompatible change. Then you'd need to use a session-local defining function for defining those properties, one that restores the startup state after each session. Here is some stone-age patch where you can see how the first step would look in Scheme (the C++ part would no longer apply since lily_module_constant has been superseded by the lily-imports.{cc,hh} files). All previous such "extensions" dabbling in internals would stop working. So would previous checks for these properties (it's conceivable to redefine the old object property accessor functions as they are not likely to be used outside of LilyPond and a bit of performance impact for legacy use would be tolerable). >From b9ac44461c15db57cd8346053d8276e405487e53 Mon Sep 17 00:00:00 2001 From: David Kastrup Date: Wed, 15 Apr 2015 17:47:07 +0200 Subject: [PATCH] wip --- lily/include/lily-guile-macros.hh | 5 + lily/parser.yy| 6 ++ scm/define-grobs.scm | 7 +-- scm/document-translation.scm | 2 +- scm/music-functions.scm | 10 +++--- 5 files changed, 16 insertions(+), 14 deletions(-) diff --git a/lily/include/lily-guile-macros.hh b/lily/include/lily-guile-macros.hh index 5fc1c8e..984ebf1 100644 --- a/lily/include/lily-guile-macros.hh +++ b/lily/include/lily-guile-macros.hh @@ -215,6 +215,11 @@ void ly_check_name (const string &cxx, const string &fname); #define set_object(x, y) internal_set_object (ly_symbol2scm (x), y) #define del_property(x) internal_del_property (ly_symbol2scm (x)) +#define ly_set_object_property(name, object, value) \ + (scm_call_2 (scm_setter (ly_lily_module_constant (name)), object, value)) +#define ly_get_object_property(name, object)\ + (scm_call_1 (ly_lily_module_constant (name), object)) + #ifndef NDEBUG /* TODO: include modification callback support here, perhaps diff --git a/lily/parser.yy b/lily/parser.yy index 2c324f5..a43ac31 100644 --- a/lily/parser.yy +++ b/lily/parser.yy @@ -2444,8 +2444,7 @@ grob_prop_spec: SCM l = scm_reverse_x ($1, SCM_EOL); if (scm_is_pair (l) && to_boolean - (scm_object_property (scm_car (l), - ly_symbol2scm ("is-grob?" + (ly_get_object_property ("is-grob?", scm_car (l l = scm_cons (ly_symbol2scm ("Bottom"), l); if (scm_is_null (l) || scm_is_null (scm_cdr (l))) { parser->parser_error (@1, _ ("bad grob property path")); @@ -2554,8 +2553,7 @@ simple_revert_context: $1 = scm_reverse_x ($1, SCM_EOL); if (scm_is_null ($1) || to_boolean - (scm_object_property (scm_car ($1), - ly_symbol2scm ("is-grob?" { + (ly_get_object_property ("is-grob?", scm_car ($1 { $$ = ly_symbol2scm ("Bottom"); parser->lexer_->push_extra_token (@1, SCM_IDENTIFIER, $1); } else { diff --git a/scm/define-grobs.scm b/scm/define-grobs.scm index 252733d..658fe67 100644 --- a/scm/define-gro
Re: Add output-attributes grob property to replace id (issue 308430043 by paulwmor...@gmail.com)
Patch Set 2: Improve convert rule, keep id property. https://codereview.appspot.com/308430043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel