Re: Gets vertical skylines from grob stencils (issue 5626052)

[dak]

On 2012/02/23 14:09:12, MikeSol wrote:
> On 2012/02/23 13:35:29, dak wrote:
> > On 2012/02/23 12:37:04, MikeSol wrote:
> > >
http://codereview.appspot.com/5626052/diff/40001/lily/stencil-integral.cc
> > > File lily/stencil-integral.cc (right):
> > >
> > >
> >

http://codereview.appspot.com/5626052/diff/40001/lily/stencil-integral.cc#newcode932
> > > lily/stencil-integral.cc:932: MAKE_SCHEME_CALLBACK (Grob,
> > > simple_vertical_skylines_from_possibly_transparent_stencil, 1);
> > > On 2012/02/23 12:29:06, dak wrote:
> > > > Why do we need this?  I think that a _transparent_ stencil is
not supposed
> > to
> > > > create a different skyline.  That's the point of setting
transparency
> rather
> > > > than just #f-ing the stencil.
> > >
> > > The problem is TabStaff and TabVoice.  In both contexts, many
grobs are set
> to
> > > transparent as a default.  These are grobs that are never supposed
to factor
> > > into a vertical skyline.  I'd be interested in seeing what happens
if these
> > were
> > > set to ##f instead of transparent, but that'd be a new project.
> >
> > a) the behavior is expected and consistent
> > b) http://code.google.com/p/lilypond/issues/detail?id=2085 is fixed
and
> verified
> >
> > Setting that stuff to "transparent" is merely an ugly workaround
used for
> > historical reasons.  We should not create inconsistent and complex
semantics
> to
> > half-heartedly support it.

> So, just to be clear, you're saying that the TabVoice/TabStaff
> everything-is-transparent-when-it-should-be-##f issue is blocking this
patch?
> If so, I'll open up an issue for that and mark this as blocked.

No, it isn't blocking this patch.  Ugly before -> ugly afterwards is not
a regression.  In particular not Ugly before because of historically
motivated user-code level workarounds with expected effects -> ugly
afterwards because of historically motivated user-code level workarounds
with expected effects.

One can't even call them "sideeffects".  You can open an issue for
fixing all the "transparent" examples in our code base and possibly
detecting more cases where #f does not work as expected.

But it is not blocking this patch.  It is orthogonal to this patch, and
you should keep it that way instead of complicating your patch by
introducing weird stuff for fixing an unrelated problem in the user-code
level code base.

http://codereview.appspot.com/5626052/