TextFlow and Min vs. Pref size

[Danno Ferrin]

Perhaps the approach FlowPane takes should be done.

The contentBias for the text node depends on the principal character set,
horizontal for western/european fonts and vertical for eastern/asian fonts
(gross overgeneralization).  Whether this is autodetected or set as a
property is up for discussion.  Mixed layouts cause a problem.

Then the minWidth/Height depends on the bias.  For western fonts
calculateMinHeight returns calculatePrefHeight, vice versa for vertical
fonts.  A Bias of null has the current behavior.  The other dimension's
calculation does the same thing it does currently.

This is what I do to workaround in my toy app.  I make a custom VBox that
returns the pref height for the minHeight.

On Mon, Dec 3, 2012 at 11:13 AM, Felipe Heidrich <felipe.heidrich at oracle.com
> wrote:

> Hi,
>
>
> It was not an oversight but not something I play around all that much.
>
> The behavior is described in the javadoc:
> preferred size is ideal size where no line needs to wrap.
> minimal size is the for padding, nothing more. When the width is between
> min size and pref size lines will wrap.
> maximum size is unbounded.
>
> I think the problem was I couldn't define minimal size any another way ?
> What else could it be, lines just wrap "a little bit" ?
>
> In my tests when I made minimal equals to preferred what happened was that
> I could not longer resize the parent container so that lines would wrap.
>
> I'm out of town this week but I'll do my best to try your snippet, please
> feel free to file a jira if you preferred. I'm more than glad helping out
> or even modifying the behavior.
>
> Regards,
> Felipe
>
>
> On Dec 2, 2012, at 9:20 PM, Danno Ferrin wrote:
>
> > I was playing with the TextFlow bits in the JDK8 ea and was wondering
> about
> > the handling of min vs pref sizing.  The TextFlow can return some very
> > small min sizes which are much smaller than the contained text elements.
> > For example, I have a text with min/pref/max all of 269.85 x 30.62 while
> > the min/pref/max of the parent TextFlow (which contains just the text
> node)
> > of 0.0 x 17.2 / 269.85 x 48.62 / maxValuexmaxValue.  This is problematic
> > when place in a scroll pane, as all the text flows tend to bunch up on
> each
> > other.
> >
> > Is this a design intent or an oversight?
> >
> > For a workaround I've wrapped then TextFlows in panes that report
> minHeight
> > as PrefHeight, so I don't see the bunching in scrollpane problem.
> >
> > For an interactive example of this behavior I have a toy app at
> bitbucket:
> > https://bitbucket.org/shemnon/flowdown
>
>


-- 
There is nothing that will hold me back.  I know who I am....
I remember wher I came from, and I feel stronger for knowing.
Zane, Ninja of Ice.  Ninjago S01E07