Sorry we flew off the list accidentally. I like BASELINE_OFFSET_SAME_AS_HEIGHT. This change in behavior will potentially break other layout managers which are handling the baseline case. Specifically, we should test with MigLayout. Otherwise this seems like a significant improvement in that we can avoid multiple passes and also correct layout the first time around instead of having things in the wrong place the first time, only to be moved around the next pass.
Richard On Sep 3, 2013, at 9:50 PM, Martin Sladecek <martin.slade...@oracle.com> wrote: > Maybe the USE_COMPUTED_BASELINE_OFFSET should be rather > BASELINE_OFFSET_SAME_AS_HEIGHT. > It's up to the layout container to compute the baseline of such Node, as the > layout container must compute the height as well. > Currently, the layoutBounds height is returned, but this is incorrect, as the > layoutBounds contain the old width&height and will be updated during the > layout. > > So it actually means, for the baseline of this Node, use it's newly computed > height. > > -Martin > > On 09/03/2013 09:45 PM, Richard Bair wrote: >> I must be missing something. I thought the getBaselineOffset method was the >> means by which that was done? Meaning, if I'm a layout container, then I >> would call getBaselineOffset to get this value. Now, I call it and it tells >> me USE_COMPUTED_BASELINE_OFFSET, so how do I compute it? Or do you mean, if >> somebody gets USE_COMPUTED_BASELINE_OFFSET, then it really means, use the >> layoutBounds height? >> >> Richard >> >> On Sep 3, 2013, at 12:37 PM, Martin Sladecek <martin.slade...@oracle.com> >> wrote: >> >>> The layout container will need to compute the baseline for Nodes with >>> USE_COMPUTED_BASELINE_OFFSET, because it's the layout container who needs >>> to compute the child's height (which is equal to it's baseline). I've >>> prepared the code of all the layout Panes so that the baseline is computed >>> after the heights and the heights are computed with respect to the >>> baseline. There are many package-private helper methods in Region that I've >>> updated and used in our layout Panes, so it's a matter of a few calls for >>> us, but 3rd party layouts will have to compute this by themselves (as they >>> aways had). >>> >>> -Martin >>> >>> On 09/03/2013 05:56 PM, Richard Bair wrote: >>>> So how does the layout container ask for the computed baseline offset? It >>>> used to be, by calling this method. >>>> >>>> Richard >>>> >>>> On Sep 3, 2013, at 6:11 AM, Martin Sladecek <martin.slade...@oracle.com> >>>> wrote: >>>> >>>>> Hi, >>>>> related JIRA issue: https://javafx-jira.kenai.com/browse/RT-31006 >>>>> >>>>> I propose to add constant "public static final double >>>>> USE_COMPUTED_BASELINE_OFFSET" to Node class. >>>>> >>>>> This would be returned by the default Node implementation of >>>>> getBaselineOffset. Currently, the layout bounds are returned, but they >>>>> are not computed at the time getBaselineOffset is called, which leads to >>>>> incorrect layout and other problems (see more in description of the >>>>> issue). >>>>> >>>>> Thanks, >>>>> -Martin >
