TextFlow and Min vs. Pref size

[Felipe Heidrich]

Hi,

Sorry for the delay, I was out of office quite a few times in the last couple weeks.

I have updated the jira report. I believe you are right about min height, it should call pref height.
I'll test the case and fix the code, shall we move the discussion to the jira ?

Thanks
Felipe


On Dec 19, 2012, at 2:13 PM, Danno Ferrin wrote:

> I've posted a bug on this ( http://javafx-jira.kenai.com/browse/RT-26719) and the screenshots show just how much of a problem this is.
> 
> The min/pref width can remain as is, when a flow is constrained by height there is no real consideration since the flow is horizontal.
> 
> But what is critical to me is the height, when given X pixels to render across how many vertical pixels are needed to render.  Especially since scroll pane relies on the minimum height for the default sizing and not preferred size (which seems weird).
> 
> Is there any work going on for that bug?
> 
> On Tue, Dec 4, 2012 at 6:57 AM, Felipe Heidrich <felipe.heidrich at oracle.com> wrote:
> 
> In the FlowPane the children are Nodes that can have well defined min and pref width.
> So the wrapping algorithm can run asking the children for their min width when the min width of the FlowPane is requested, and asking the children's pref width  when the FlowPane's pref width is requested.
> 
> The TextFlow, on the other hand, the content is text, where the width is the sum of the advance width of the glyphs. It doesn't have the notion of min width and pref width. Not sure how the same approach could be used.
> 
> Currently TextFlow doesn't not support vertical text, so the content bias is always horizontal, height depends on the width.
> 
> Felipe
> 
> 
> 
> On Dec 3, 2012, at 2:50 PM, Danno Ferrin wrote:
> 
> > 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
> >
> 
> 
> 
> 
> -- 
> 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
>