Re: Allows inner-markup spacing using skylines. (issue 13341044)

[Mike Solomon]

On 29 août 2013, at 10:25, address@hidden wrote:

> On 2013/08/29 06:57:53, MikeSol wrote:
>> The point is to allow users to achieve the same snug skyline spacing
> between
>> stencils that is achieved between grobs.
> 
>> I agree that it is inefficient as skylines are never cached, but as it
> is not
>> default beahvior anywhere in the code base, it allows people to decide
> on the
>> efficiency versus snugness-of-placement trade-off.  For people
> creating complex
>> markups, this is useful.
> 
> Mike, the question is not whether or not it is useful to work with the
> distance of skylines.  The problem is that you just pile on complex
> derived functionality nilly-willy without stopping to think what the
> actually sensible building blocks would be.

What would they be?

> 
> 
> The solution is to add _proper_ interfaces to skylines.  Functions
> that can figure out distances and so on.  Between skylines.
> 

Doesn't that exist already with Skyline::distance ?

> And a function to query the skyline(s) of a stencil, yes.
> 

Doesn't this already exist with Stencil::skyline_pair_from_stencil and 
Stencil::skyline_from_stencil (proposed in this patch) or the function in 
current master Stencil::skylines_from_stencil ?

> Now querying skylines is expensive, so the question is how to cache
> them.

Agreed.

> The important thing to note is that skylines are not actually a
> property of stencils but rather of stencil expressions (combined
> stencils don't actually contain the original stencils but only their
> respective stencil expressions, so caching in the stencils themselves
> does not actually help at all).

If skylines rode around with stencils (like dimensions do), we'd have to do 
operations on the skylines when we do operations on the expression and 
dimension.

> The current form of stencil
> expressions does not make it easy to tack a skyline cache on without
> changing object identity, so it might be worth considering a different
> representation.

This is certainly a possibility.

> 
> Once that's sorted out satisfactorily and supported by primitives, one
> can stack on uses of skylines.
> 
> But increasing the number of functions that magically and
> intransparently somehow work with skylines not otherwise accessible is
> just a bad idea, and hiding this kind of thing in existing functions
> is even worse.

It would be a good idea to have Scheme bindings for skylines and to make them 
accessible, similarly to how dimensions are extensible and changeable.

What is your proposal for a good interface with Skylines?  This patch allows 
one to ask LilyPond "find the distance between two stencils' shapes along the 
horizontal or vertical axis and move shift a stencil by that amount" and 
LilyPond does that.  Where is there transparency needed?  In 
side-position-interface.cc and axis-group-interface.cc, the skyline operations 
are not transparent (meaning not visible to the user) but the end result (move 
object X above or below Y based on the shapes of the objects) is achieved.  It 
is also not transparent, but I wouldn't have thought it needed to be - I think 
people just want it to work and we should do a good job implementing it 
cleanly.  I'm of course open to proposals on how to implement it cleanl.y

Cheers,
MS