Project - Eliminating grob parents and outside-staff-priority

[address@hidden]

Hey all,

As was the case in a few of my previous projects, before I start something new 
I make architecture changes that facilitate my work.  Working on 2801, I've 
realized that any multi-pass algorithm for the spacing of grobs is difficult 
because results of callback calculations are always cached.  So triggering 
callbacks a second time is, in the current architecture, impractical and 
requires a fair bit of kludgery.

To start this process, I'd like to expand the role of the 
side-position-interface significantly.  All grobs would use this interface for 
their X and Y offsets and they would have two different grob arrays for X and Y 
side-position-elements.  This would allow me to eliminate two things:

1) parents.  Grobs are X/Y aligned to parents, but these parents could be 
elements in the side-position-elements array.  Functions like get_parent, which 
could be kept around for legacy reasons, could return the first element of 
these arrays for a given axis and raise a warning if there are multiple 
elements.

2) outside-staff-priority.  Saying a grob has outside staff priority is the 
same thing as saying that a grob has as its Y side support elements all 
inside-staff grobs plus all grobs with lower outside staff priority.  A 
callback creating the side-position-elements arrays could do the sorting that 
takes place in Axis_group_interface::skyline_spacing.

The benefits of this are twofold:

1) All work on a multi-pass algorithm could be done with respect to 
side-positioning, making it simpler to find bugs and modify code.
2) A call to translate_axis in avoid_outside_staff_collisions would be 
eliminated, and translate_axis is bad: it goes against the callback model at 
the core of LilyPond layout.

The disadvantage is that this results in the construction of many more skylines 
(one for each call to Side_position_interface::skyline_side_position).  How 
this will impact performance is uncertain, but it'd probably require more 
optimization in skyline.cc and/or caching of skylines.

Before I do this, which will take me several months, does anyone have any 
objections?  Do people think it's a good idea?

Cheers,
MS