On Wed, Sep 26, 2012 at 12:17 PM, m...@mikesolomon.org <m...@mikesolomon.org > wrote:
> On 26 sept. 2012, at 17:38, Joe Neeman <joenee...@gmail.com> wrote: > > On Wed, Sep 26, 2012 at 4:15 AM, m...@mikesolomon.org < > m...@mikesolomon.org> wrote: > > > 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. >> > > If you get rid of unique parents, what would X-offset mean? Would it be > relative to the System? The first element of side-position-elements array? > > > Relative to the skyline of the elements of the side-position-elements > array. > If you want to construct one skyline for all the elements in that array, you need some way of finding their offsets relative to each other. How do you propose to do that without some notion of a common refpoint? 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. >> > > I think you'll have trouble making this fully callbacky/functional. For > example, we lay out the outside-staff grobs in a very particular order (the > left-to-right layout thing), which we don't know ahead of time. That is, > until we get _all_ of the outside-staff grobs together, we don't know which > grobs have to depend on which other grobs. That means it isn't really > possible for each grob to determine its own position; there needs to be one > grob that lays them out simultaneously. The same issue will come up, I > think in laying out Accidentals and VerticalAxisGroups. > > > You're right that, in general, any time that a collecting grob does some > type of organizing, this type of problem will come up. However, there are > ways around it. For example, a grob can get the elements array from its > vertical alignment or system, sort it from left to right, and trigger > callbacks for all grobs to the left. This avoids an overarching > positioning grob while still achieving the same effect. > For outside-staff positioning, I think you could achieve the same effect. For something more complicated, like TieColumn or AccidentalPlacement, I think it would be much more difficult (and more obfuscated) to do it with callbacks. > >> 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. >> > > Not all positioning is side-positioning. > > > True - my goal is to see if all positioning can be articulated this way. > For example, ScriptColumn could have used translate_axis, but whoever > wrote it made the good decision to use side-position-interface. I think > this grob could be eliminated entirely if all scripts in a script column > had a function that calculated the side-position-elements grob-array using > the sorting algorithm at the heart of script-column.cc. > > Another way to think of this is that, in general, we'd try to eliminate > grobs like NoteColumn, ScriptColumn, DynamicLineSpanner, etc that only do > traffic-coppery. Or, inversely, we'd say that positioning only happens via > traffic-cop grobs and no grob has the right to position itself. But it > seems like we need to pick one. > I gave this some thought a while ago, and concluded that it isn't possible to get rid of the traffic cops (however, I'd be happy to be proven wrong). My eventual decision was to have them everywhere. A grob could suggest its own position using a callback, and if no other grob wanted to override that, then the System grob would take the traffic cop role and set the grob's position to whatever its suggestion was. That way you could write a lot of the positioning code as callbacks, and the cops would only kick in where necessary. There were also explicit dependencies so you could figure out which grob was in charge of positioning for which other grob. Cheers, Joe
_______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
