Re: Project - Eliminating grob parents and outside-staff-priority

[address@hidden]

On 26 sept. 2012, at 14:13, David Kastrup <address@hidden> wrote:

>> What we need to arrive at is a situation where somebody without a clue
> starting to write stuff will more likely than not get a whole lot of
> things working right without realizing it, rather than getting a whole
> lot of things working wrong without realizing it.

I completely agree.

> 
> Which apparently is what is happening to Marc right now.  He is working
> on a simple problem, and it fails for complex reasons.  And that means
> the current design of our backend is bad.
> 
> Conceptually simple problems need to map to conceptually simple
> solutions.  If they don't, our APIs suck.

We don't have APIs, which is a separate but equally problematic issue.

The conceptually simple problem is that grobs are positioned with respect to 
other grobs.  The conceptually simple solution is that grobs contain arrays of 
these other grobs and use them for the positioning.  That's why I want to make 
this change - it provides one-stop-shopping for positioning changes.

> 
>> I think the change decreases complexity as it makes LilyPond more
>> predictable and boring - objects side position based off of other
>> objects and that's it.  No need for side-position, parents and
>> outside-staff-priority.
> 
> parents are used for a _lot_ of positioning, and for example the
> determination of a common grob parent is an _efficient_ operation.  So
> it might make sense to solve the problem you are thinking of via
> artificial/grouping parents.

This is totally possible - you check the side-position-elements array, and if 
it has multiple members, you find their common refpoint.  This can go all the 
way up to System and VerticalAlignment, both of which will have 
side-position-element arrays of size 0 for both the X and Y axes.

Cheers,
MS