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