Re: Accessing Grob properties

[David Kastrup]

Urs Liska <address@hidden> writes:

> Am 18.01.2016 um 20:20 schrieb Urs Liska:
>> Am 18.01.2016 um 18:37 schrieb Simon Albrecht:
>>> On 18.01.2016 18:27, Urs Liska wrote:
>>>> Am 18.01.2016 um 18:24 schrieb Kieren MacMillan:
>>>>> Hi Urs,
>>>>>
>>>>>> c)
>>>>>> Take a) as the default and provide a context property
>>>>> This.
>>>>>
>>>>> Thanks,
>>>>> Kieren.
>>>>>
>>>> Any suggestions for a better name than
>>>>
>>>>      \set subdividedBeamCountAddForShortenedBeam = ##t
>>> It would almost call for
>>> \override Beam.subdivide-details.ignore-shortening = ##f
>>> (this would be the default). Still a bit clumsy, and I don’t want to
>>> upturn your plans. But the options seem to be complex enough to be
>>> better stored in an alist.
>> I find this a very good idea. I don't feel very good with inventing
>> arbitrary independent context properties. Having a single object and
>> consistent interface would make it much more consistent to add more
>> configuration options to the beaming.
>>
>> That wouldn't bother my "plans" at all, it's just that I don't know out
>> of my hat where to define (and initialize) such an alist and how to
>> access its value from within the C++ beaming code. So any hints welcome ...
>>
>> Best
>> Urs
>
> I am now trying to implement configuration through
>
>     \override Beam.subdivide-details.beam-count = #'metric
>     \override Beam.subdivide-details.ignore-shortening = ##f
> etc.
>
> but I don't see the proper way of doing so (in C++).
>
> I am able to retrieve the property value somewhere in the Beam class
> (beam.cc), but I don't seem to manage to get that information into
> Beaming_options or Beaming_pattern.
> Is it possible that the Beam object is only created when the
> Beaming_pattern has already been completed?

Maybe, but the beaming options are fetched at start time via

lily/auto-beam-engraver.cc:244:  beam_settings_ = Grob_property_info (context 
(), ly_symbol2scm ("Beam")).updated ();

> Apart from that question I'd ask more generally:
> How could I manage to get hold of the values in a Beam.subdivide-details
> alist from within Beaming_pattern::beamify?

Using calls of scm_assq_ref or so?

-- 
David Kastrup