On Dec 15, 2013, at 12:58 AM, Keith OHara <k-ohara5...@oco.net> wrote:
> On Sat, 14 Dec 2013 00:49:43 -0800, Mike Solomon <m...@mikesolomon.org> wrote:
>
>> On Dec 14, 2013, at 9:35 AM, David Kastrup <d...@gnu.org> wrote:
>>
>>> Most of the contortions seem focused about when or when not and how to
>>> pass begin/end columns. It would seem to make sense to turn them into
>>> dynamic parameters *begin* *end* that you can then query with (*begin*)
>>> and (*end*). If (*begin*) returns ##f, we can assume being in a pure
>>> calculation.
>>>
>>> That would seem to get rid of most of the current interface
>>> complications.
>>
>> I can see the utility of having one function instead of two for these things.
>>
>> The current pure and non-pure functions are often wrappers around a single
>> internal function that has a bool parameter called “pure”, so this would
>> eliminate the need for the wrapper functions.
>>
>
> The word 'pure' might have too much a connotation as 'good'. Maybe we should
> rename 'pure' ->
> ‘shitty_hack_estimate_because_I_am_unable_to_order_layout_decisions_better_please_forgive_me'
>
I prefer the second name, with the corollary that pure heights and pure
anythings are the largest implementation of a basic strategy all over the code
base, which is:
elaborate several options
score them
pick the one with the highest score
This happens for slurs, beams, ties, and line breaking. In the case of line
breaking, the elaboration of the options entails making estimates, which is why
we calculate pure heights.
> --
> The most transparent reorganization might be to have all properties that can
> hold data use the usual callback mechanism: where the callback function is
> used just once, and the data it returns takes the place of the callback.
This is indeed transparent, but given that a single object can return many pure
heights based on the begin/end values being used or based on how far downstream
we are, it’s not clear what this property would look like.
>
> The layout engine could use get_property_data() freely, but before it has set
> line-breaks the layout engine would refrain from calling any callback
> functions directly. Instead of a callback for 'height', layout functions
> would look up the grob property 'tentative-height-estimator' where
> tentative-*-estimators are always functions that take the start-end columns
> as parameters.
This seems not too far from what we’re doing now, but it adds a lot more
properties.
>
> The tentative-height-estimator for something like a Slur or VerticalAxisGroup
> would return its best guess for the height, while the estimator for a Clef
> would simply get_property("height") causing its stencil to be formed and
> leaving the resulting data in the 'stencil' and 'height' properties for
> further use.
>
This seems to get the same result we have now while adding a lot of extra
properties.
I like the idea of their being a single property that is honed in on with
successive estimates until we get the perfect value. This is how I do a Sudoku
- I pencil the guesses in the squares until I get the actual value and then
erase all the estimates and write the good value. Something about using the
container (the property) as a holder of the estimates and the final item itself
feels sound design-wise.
Cheers,
MS_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
