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/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
