Re: GSOC: change XY-extent to outer-XY-extent and inner-XY-extent (design - feedback requested)

[Janek Warchoł]

Hi Joe,

On Mon, Jun 18, 2012 at 1:23 PM, Joe Neeman <address@hidden> wrote:
> I think that what you propose can be done more generically using
> higher-order functions to build grob callbacks. This would have two main
> advantages that I can see: it would allow each grob to have more than one
> "core extent" to be used in different contexts, and it would allow those
> "core extents" to be referenced using meaningful names.

(this is probably a stupid question, but i'm not confident enough with
terminology yet:) You mean to create functions similar to these ones
(from self-alignment-interface):

// this just calls aligned_on_parent with specific argumments
MAKE_SCHEME_CALLBACK (Self_alignment_interface, aligned_on_y_parent, 1);
SCM
Self_alignment_interface::aligned_on_y_parent (SCM smob)
{
  return aligned_on_parent (unsmob_grob (smob), Y_AXIS);
}

// this one actually does the job
SCM
Self_alignment_interface::aligned_on_parent (Grob *me, Axis a)
{
  [....]
}

..?
If yes, that's exactly what i wanted to do.  I'm just wondering what
needs to be done apart from writing these functions, and how to do
this without creating a royal mess :)

>Consider the example:
>
> #(define (ly:aligned-on-X-parent-using sym)
>  (lambda (grob)
>   (let ((grob-extent (ly:grob-property grob sym))
>    ...
>    ;; do the alignment, but using the result of looking up 'sym instead of
> the grob's extent
> )))
>
> \override LyricText #'non-punctuation-extent =
> #(some-callback-that-computes-the-right-thing)
> \override LyricText #'X-offset = #(ly:aligned-on-X-parent-using
> 'non-punctuation-extent)

I suppose this is exactly what i've written above, but in Scheme?

> If someone then decides that they also want numbers to be excluded, then
> they can write a non-punctuation-or-number-extent callback and do
> \override LyricText #'X-offset = #(ly:aligned-on-X-parent-using
> 'non-punctuation-or-number-extent)
> I think that we could provided a lot of functionality (and flexibility) by
> providing a selection of functions like ly:aligned-on-X-parent-using and a
> selection of callbacks to use them with.

That's my impression, too.

> Whatever design you pursue, I think it's worth keeping around the old
> X-extent and Y-extent names, if only so that there is no painful transition.

Probably.  I guess XY-extent would mean the outer extent.

> Actually, it seems like extents are gradually being replaced by more
> accurate outlines (ie. skylines) anyway, but they are probably still useful
> for certain things.

Indeed, extents should be replaced by skylines for calculating
distances and collisions.  However, i think that extents will be still
needed for alignment purposes: for example, a skyline might not be
enough for determining object's center to which we want to align
something.

thanks!
Janek