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