baseline update

[Noel Grandin <no...@gmail.com>]

Hi

This is what I've got so far with my my baseline implementation - how
does it look?

Basic architecture
- VerticalAlignment gets a new constant BASELINE
- ConstrainedVisual has a new method
     public int getBaseline(int width);
  I had to put the method at a higher level than Component because I
also need to call it on
  Skin and Renderer instances. 
- ComponentSkin has a static flag for debugging support for baselines,
  which draws red lines on the components to make it easier to see where
the problems are.
  To turn it on, pass
    -Dpivot.wtk.debugBaseline=true
  on the command line
 
TODO
- I'm unsure how best to calculate a baseline for TextAreaSkin
- TablePaneSkin still needs a getBaseline() implementation
- FlowPaneSkin - It is possible to end up with illegal combinations e.g.
  verticalAlignment==BASELINE && orientation==VERTICAL. But how to flag
these kinds of errors?
 
 
Regards, Noel.

Re: baseline update

[Sandro Martini <sa...@gmail.com>]

Ok, thanks for the moment.

Sandro

Re: baseline update

[Noel Grandin <no...@gmail.com>]

Hi

I seem to have lost my demos somewhere while updating my workspace, will
have to recreate.

But I changed FormPane to default to baseline alignment, so any Forms
demos will show the difference.

I'll recreate my demos later.

Regards, Noel.

Sandro Martini wrote:
> Hi Noel,
> great work, i hope to find some time to look at the code ...
>
> Have you got a Test class, to simplify our Test Runs ?
>
> Bye,
> Sandro
>   

Re: baseline update

[Sandro Martini <sa...@gmail.com>]

Hi Noel,
great work, i hope to find some time to look at the code ...

Have you got a Test class, to simplify our Test Runs ?

Bye,
Sandro

Re: baseline update

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

Ah, OK. Makes sense.

On Jun 9, 2009, at 10:10 AM, Noel Grandin wrote:

> Greg Brown wrote:
>>> It's an offset from the top of the component, where -1 indicates no
>>> baseline.
>>
>> Might it simplify the code if we defined it as an offset from the
>> bottom of the component, where 0 means no baseline?
>>
> I picked the convention that matched the approach Swing used for their
> baseline support (in 1.6), and the coordinate system used in AWT's
> Graphics2D class.
> It doesn't make much difference to the complexity of the code.
>

Re: baseline update

[Noel Grandin <no...@gmail.com>]

Greg Brown wrote:
>> It's an offset from the top of the component, where -1 indicates no
>> baseline.
>
> Might it simplify the code if we defined it as an offset from the
> bottom of the component, where 0 means no baseline?
>
I picked the convention that matched the approach Swing used for their
baseline support (in 1.6), and the coordinate system used in AWT's
Graphics2D class.
It doesn't make much difference to the complexity of the code.

Re: baseline update

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

> It's an offset from the top of the component, where -1 indicates no
> baseline.

Might it simplify the code if we defined it as an offset from the  
bottom of the component, where 0 means no baseline?

> In a ideal world, TablePaneSkin would return the max(baseline) over  
> the
> child components in the first row.

The first row seems arbitrary. I could see making this argument for a  
horizontal flow pane - maybe for TablePane the caller could specify  
the row that defines the baseline.

> The problem with throwing is that the caller may be transitioning from
> one valid state to another via an invalid state, but because we set  
> the
> properties using 2 different methods, it is impossible to know if this
> is the case.

I don't think that is a problem here, because "orientation" is an  
intrinsic property of FlowPane and alignment is a style. Setting the  
intrinsic property would reset the style - we wouldn't throw in this  
case.

Re: baseline update

[Noel Grandin <no...@gmail.com>]

Greg Brown wrote:
>> - I'm unsure how best to calculate a baseline for TextAreaSkin
>
> How do components report their baseline? Is it an offset from the
> bottom of the component, or from the top? I think I would expect the
> bottom - if so, I would expect TextArea's baseline to be 0.
>
It's an offset from the top of the component, where -1 indicates no
baseline.

>> - TablePaneSkin still needs a getBaseline() implementation
>
> Could this also be 0? It seems like many components might want to
> report 0 - how do some other components (besides Label) define their
> baselines?
>
The default implementation in ComponentSkin returns -1, which indicates
"no baseline".
In a ideal world, TablePaneSkin would return the max(baseline) over the
child components in the first row.
Besides Label, FlowPane, CardPane, StackPane, Checkbox, Form,
LinkButton, ListButton, ListView, PushButton, RadioButton, Sheet,
Spinner, TextInput return valid baseline values.

>> - FlowPaneSkin - It is possible to end up with illegal combinations e.g.
>>  verticalAlignment==BASELINE && orientation==VERTICAL. But how to flag
>> these kinds of errors?
>
> If a caller tries to set an incompatible alignment style, we could
> throw. If the caller changed the FlowPane's orientation after the
> style had been set, we could just revert it to the default value
> (rather than throwing). I'm actually considering eliminating support
> for HorizontalAlignment.JUSTIFY when Orientation is HORIZONTAL and
> VerticalAlignment.JUSTIFY when Orientation is VERTICAL*, and we would
> probably want to handle this case the same way.
>
The problem with throwing is that the caller may be transitioning from
one valid state to another via an invalid state, but because we set the
properties using 2 different methods, it is impossible to know if this
is the case.
> * In retrospect, the use cases for these combinations seem somewhat
> artificial, and the code to support it is non-trivial; I need to make
> some optimizations to this class anyways, so I was thinking of bagging
> it while I was in there.
>

Re: baseline update

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

> - I'm unsure how best to calculate a baseline for TextAreaSkin

How do components report their baseline? Is it an offset from the  
bottom of the component, or from the top? I think I would expect the  
bottom - if so, I would expect TextArea's baseline to be 0.

> - TablePaneSkin still needs a getBaseline() implementation

Could this also be 0? It seems like many components might want to  
report 0 - how do some other components (besides Label) define their  
baselines?

> - FlowPaneSkin - It is possible to end up with illegal combinations  
> e.g.
>  verticalAlignment==BASELINE && orientation==VERTICAL. But how to flag
> these kinds of errors?

If a caller tries to set an incompatible alignment style, we could  
throw. If the caller changed the FlowPane's orientation after the  
style had been set, we could just revert it to the default value  
(rather than throwing). I'm actually considering eliminating support  
for HorizontalAlignment.JUSTIFY when Orientation is HORIZONTAL and  
VerticalAlignment.JUSTIFY when Orientation is VERTICAL*, and we would  
probably want to handle this case the same way.

* In retrospect, the use cases for these combinations seem somewhat  
artificial, and the code to support it is non-trivial; I need to make  
some optimizations to this class anyways, so I was thinking of bagging  
it while I was in there.