Baseline alignment

[Greg Brown <gk...@mac.com>]

One thing I have wondered about is whether it might be better to  
define getBaseline() as a no-arg method, rather than having it take a  
width constraint argument. This way, baseline would always be defined  
as relative to the current size. 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.

There may be issues with the idea - not sure. However, if it helps  
simplify the solution to the min. aspect ratio issue in PushButton, it  
might be worth considering.

G

Re: Baseline alignment

[Greg Brown <gk...@mac.com>]

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" <tv...@gmail.com> 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 <gk...@mac.com> 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
>>>
>>
>>
>
>

Re: Baseline alignment

[Todd Volkert <tv...@gmail.com>]

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 <gk...@mac.com> 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
>>
>
>

Re: Baseline alignment

[Greg Brown <gk...@mac.com>]

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

Re: Baseline alignment

[Todd Volkert <tv...@gmail.com>]

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