Re: Issue 2507: Stop the entanglement of context properties and grob property internals (issue 126280043 by d...@gnu.org)
Fix incredibly reckless context/grob property mixup in event-listener I would rather call this clueless :-) https://codereview.appspot.com/126280043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2507: Stop the entanglement of context properties and grob property internals (issue 126280043 by d...@gnu.org)
On 2014/08/15 06:11:31, lemzwerg wrote: Fix incredibly reckless context/grob property mixup in event-listener I would rather call this clueless :-) Ill-advised would be an understatement since this is not just poking into internal data structures in a way that happens to work by chance, but it is doing so in a way that tends to deliver stale data for any properties set outside of the bottom context. At any rate, discovering this problem is actually a good argument for this patch in the first place. https://codereview.appspot.com/126280043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2507: Stop the entanglement of context properties and grob property internals (issue 126280043 by d...@gnu.org)
At any rate, putting Graham in the Cc since event-listener.ly or equivalent code is purportedly used in Vivi. The change in event-listener.ly is independent of this issue itself and should be applied to any similar code in order to avoid getting flaky results. ly:context-grob-definition has been available in working state since 2004: commit 5762e8bb079db16dd31166fa0c4b2a85464b0b8b Author: Nicolas Sceaux nicolas.sce...@free.fr Date: Sun Aug 29 13:58:05 2004 + (LY_DEFINE): ly:context-grob-definition takes two arguments. https://codereview.appspot.com/126280043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2507: Stop the entanglement of context properties and grob property internals (issue 126280043 by d...@gnu.org)
On Fri, Aug 15, 2014 at 07:58:26AM +, d...@gnu.org wrote: At any rate, putting Graham in the Cc since event-listener.ly or equivalent code is purportedly used in Vivi. The change in event-listener.ly is independent of this issue itself and should be applied to any similar code in order to avoid getting flaky results. Thanks for the heads-up! Vivi turned out to be a dead end (the machine learning technique I used was really inappropriate for the problem), but I'm still doing things with lilypond output. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming callback generators for grobs
- Original Message -
From: David Kastrup d...@gnu.org
To: lilypond-devel@gnu.org
Sent: Thursday, August 14, 2014 4:28 PM
Subject: Naming callback generators for grobs
Sorry for being a few days late with this call for comments.
Please take a look at
URL:https://code.google.com/p/lilypond/issues/detail?id=4045. The
issue is that we have a number of grob callback generators that create a
callback for some grob property.
Issue 4045 is about renaming one of them. You may want to take a look
at the proposal in the code review. Basically I am waffling back and
forth over several proposals.
Here are, as far as I can see, the current relevant callback generators:
(define ((grob::calc-property-by-copy prop) grob)
(ly:event-property (event-cause grob) prop))
So calling grob::calc-property-by-copy with the name of a property
returns a function which, when called with a grob as argument, will look
up the event-cause of the grob and take the named property from that
event.
Then there is
(define ((grob::inherit-parent-property axis property . default) grob)
@var{grob} callback generator for inheriting a @var{property} from
an @var{axis} parent, defaulting to @var{default} if there is no
parent or the parent has no setting.
Some uses are in scm/define-grobs.scm, stuff like
scm/define-grobs.scm:(text . ,(grob::calc-property-by-copy 'text))
scm/define-grobs.scm:(X-offset . ,(grob::calc-property-by-copy
'X-offset))
scm/define-grobs.scm:(Y-offset . ,(grob::calc-property-by-copy
'Y-offset))
scm/define-grobs.scm:(transparent .
,(grob::inherit-parent-property
scm/define-grobs.scm- X 'transparent))
scm/define-grobs.scm:(break-visibility .
,(grob::inherit-parent-property
scm/define-grobs.scm- X 'break-visibility))
scm/define-grobs.scm:(color . ,(grob::inherit-parent-property
scm/define-grobs.scm- X 'color))
There is no particular reason that the referenced property and the grob
property calculated via a callback needs to be the same, though it will
in practice be more often than not the case.
For grob::calc-property-by-copy a few names were bounced around in the
Rietveld discussion. My last proposal regarding
grob::calc-property-by-copy were grob::from-event-property and
grob::event-property-getter. An intermediate proposal was just
grob::event-property but that is less likely to be expected returning a
callback procedure rather than a property.
What do you think?
Obviously, the same naming would want to get applied to
grob::inherit-parent-property which currently is named completely
differently.
It's rather longer, but what about get-property-from-grob-event ?
--
Phil Holmes
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
