lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Property overrides by ID (discussion)


From: Urs Liska
Subject: Re: Property overrides by ID (discussion)
Date: Fri, 7 Apr 2017 10:32:08 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0


Am 07.04.2017 um 10:16 schrieb David Kastrup:
> Urs Liska <address@hidden> writes:
>
>> Hi,
>>
>> I've done a first implementation of an ID based property override, which
>> is sort of a complement to the edition-engraver. It's significantly less
>> complex than the edition-engraver, has some advantages over it, but also
>> significant limitations.
>>
>> If you want to have a closer look you may inspect the pull request at
>> https://github.com/openlilylib/edition-engraver/pull/14.
>>
>> What it *can* do is apply any property override that could be achieved
>> with \once \override or \tweak to grobs addressed by an ID. This means
>> it isn't necessary anymore to bother with finding out when and in which
>> context the item is. Simply add an ID to it and address it, and there
>> you go, completely robust against changes in context and timing.
>>
>> However, at least at the moment, it can only affect individual grobs'
>> properties, so it's not possible to insert switches like regular
>> \override's (only \once) or actual elements like breaks, markups or
>> marks etc.
> If you use \override Grob.id then all grobs get the id until you revert.
> Wouldn't that have the desired effect?  

No, then I could directly override the property I'd need.
The basic idea *is* to be able to easily address specific grobs
(regarding the discussions about the edition-engraver where the
addressing by measure and moment is so fragile). So the 'id (or whatever
property) should be unique.

Of course I'm thinking about a system where you don't intersperse the
overrides and tweaks with the content, this is why we're looking into
external addressing in the first place. Plus, there's an increasing
probability of set-ups where the IDs are auto-generated, for example by
an importer. The idea behind that is to obtain objects tagged with an ID
from outside and being able to affect them with tweaks and overrides
without touching the actual LilyPond input.

But of course editing isn't always about changing single grobs and
inserting \override ... \revert is of course a natural use case. The
edition-engraver can do that, and now we have to discuss the best way to
integrate the different approaches in a tool that is as consistent as
possible.

> Of course, this takes away the
> possibility to use id for any other purpose or in multiple commands.  So
> maybe id is not the best idea to use here.

OTOH the natural semantic purpose of an "id" is to uniquely identify an
object. So if other use cases are disturbed by such a use (e.g. holding
additional information like a JSON object, as was discussed recently)
then maybe *these* use-cases should consider using a different property?

Urs

-- 
address@hidden
https://openlilylib.org
http://lilypondblog.org




reply via email to

[Prev in Thread] Current Thread [Next in Thread]