Hi TerraFormSkin is currently doing the right thing, modifying row height based on the relative baselines of the label and field. But even the way that TerraFormSkin uses the baselines, it is not really making use of the width argument,
I can't remember why I made this particular design choice, but I wasn't that familiar with Pivot's layout mechanism at the time. I was mostly following the lead of the AWT design. I think the best thing to do would be to remove the width argument and leave it like that until we have a clear use case for needing something more. It really wasn't that hard to introduce baselines into the code - it shouldn't be that hard to add extra baseline functionality later on. Seems like a clear case of the YAGNI principle. -- Noel. On Wed, Nov 4, 2009 at 22:49, Greg Brown <[email protected]> wrote: > I can't think of one. I think a height argument would be sufficient (even if > we don't update the FlowPane and Form skins to take it into account right > away). > > On Wednesday, November 04, 2009, at 03:42PM, "Todd Volkert" > <[email protected]> wrote: >>It's certainly more comprehensive that having getBaseline() take no >>arguments. We don't really want to suffer from a design flaw years down the >>road, so better to cover our bases now. In this aspect, I agree. The only >>question is what value a width argument could possibly provide... >> >>-T >> >>On Wed, Nov 4, 2009 at 2:16 PM, Greg Brown <[email protected]> wrote: >> >>> Apparently, the AWT Component#getBaseline() method takes a width and a >>> height. I don't think both are necessary, but it might be good to include >>> the height argument, because this will allow a container to determine its >>> preferred size based on the baselines of its children. >>> >>> Take FlowPane, for example - FlowPaneSkin#getPreferredSize() might ask each >>> subcomponent for its preferred size and then determine its own preferred >>> height using the size/position of the subcomponents relative to the baseline >>> (it doesn't currently do this, but it probably should). It would call >>> getBaseline(preferredHeight) on each subcomponent to determine the baseline >>> value, then calculate its preferred height as the difference between the >>> components whose top and bottom are farthest apart. >>> >>> TerraFormSkin might do something similar. Rather than assuming that a field >>> row is simply the max. value of the label and field heights, it could take >>> the baselines into account and determine the row height based on their >>> relative positions. >>> >>> Thoughts? >>> >>> >>> On Wednesday, November 04, 2009, at 01:11PM, "Greg Brown" <[email protected]> >>> wrote: >>> >After some additional thought, it does seem as though eliminating the >>> width argument to getBaseline() might be a good idea. Baselines are >>> primarily a layout construct - they don't generally have any bearing on >>> preferred size calculations (and, after thinking about it a bit, I'm not >>> even sure that they can). As a result, getBaseline() probably doesn't need a >>> width constraint. >>> > >>> >G >>> > >>> >On Wednesday, November 04, 2009, at 10:22AM, "Todd Volkert" < >>> [email protected]> wrote: >>> >>Actually, I'm starting to think your original assertion may be correct. >>> I >>> >>looked deeper into the problem with push button's baseline calculation as >>> it >>> >>pertains to PIVOT-338, and the buttons in the component explorer that >>> don't >>> >>report their baselines correctly aren't even given an aspect ratio -- >>> *they're >>> >>given an explicit preferred size*. The design of the existing baseline >>> >>calculation method implicitly assumes that you'll be given your preferred >>> >>size. >>> >> >>> >>Example: <PushButton wtkx:id="button" buttonData="foo" >>> preferredHeight="100" >>> >>/> >>> >> >>> >>button.getBaseline(-1) will return something like 10, when in fact the >>> >>baseline will end up being something like 55. >>> >> >>> >>Perhaps my assertion that a component's baseline may affect the preferred >>> >>size of its parent caters to an edge case condition that we really >>> shouldn't >>> >>worry about. I think I'm leaning towards re-defining the method to be >>> >>getBaseline(), and having it pertain to the existing size of the >>> component. >>> >> >>> >>Thoughts? >>> >>-T >>> >> >>> >>On Tue, Nov 3, 2009 at 8:06 AM, Greg Brown <[email protected]> wrote: >>> >> >>> >>> Ah, yes, I think that may be true. Containers must calculate their >>> >>> preferred size before they are actually given a size and called to lay >>> out. >>> >>> It stands to reason that baseline alignment may factor into that >>> >>> calculation, so you are right that we can't simplify it in this way. >>> >>> >>> >>> >>> >>> On Nov 3, 2009, at 7:56 AM, Todd Volkert wrote: >>> >>> >>> >>> Containers that can align to baseline may need to know the baselines >>> of >>> >>>> their child components when calculating preferred size (where it's >>> going >>> >>>> to >>> >>>> place the children may affect the preferred size of the container). >>> Since >>> >>>> the container has may have a width constraint in mind when it asks its >>> >>>> children for their preferred size, it stands to reason that the same >>> width >>> >>>> constraint will apply when it asks the children for their baselines. >>> >>>> Thus, >>> >>>> I think the baseline calculation has to take a width constraint. >>> >>>> >>> >>>> From a high level, it seems like this should be OK, since baseline >>> >>>> alignment >>> >>>> >>> >>>>> isn't so much about setting size as it is aligning things after their >>> >>>>> sizes >>> >>>>> have been set. >>> >>>>> >>> >>>>> >>> >>>> I think what I'm saying above is that this assumption may not be >>> correct. >>> >>>> Is it possible that a child's baseline will need to be calculated >>> during >>> >>>> the >>> >>>> preferred size calculation of its parent (and would affect the >>> preferred >>> >>>> size of the parent)? I want to say we have to assume yes, but I'm not >>> >>>> 100% >>> >>>> sure. >>> >>>> >>> >>>> -T >>> >>>> >>> >>> >>> >>> >>> >> >>> >> >>> > >>> > >>> >> >> >
