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