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 >>>> >>> >>> >> >> > >
