ScrollPane.prefViewportWidth == computed size?

Werner Lehmann lehmann at media-interactive.de
Mon Jun 3 12:28:47 PDT 2013


Hi Richard,

thanks for the quick reply. FYI, I am currently using a hardcoded value 
with some extra space, hopefully sufficient for all platforms.

On 03.06.2013 20:57, Richard Bair wrote:
> I think calling it a bug would be fair, and this approach should work.

I'll create a ticket later.

> Hmmm. I guess fitToWidth doesn't work for you because you want the
> content to dictate the size of the scroll pane, and not the other way
> around? Maybe a combination of this and a subclass to work around the
> issue you are seeing?

Exactly. fitToWidth removes the horizontal scrollbar but abbreviates the 
label text ("..."). The suggested subclass approach does not work 
because prefWidth() is final in Control. Is there any event I could 
listen for to update the prefWidth? I tried "onSceneChange" but that 
seems to be too early as prefWidth(-1) returns 0.0 then.

> Or maybe the ScrollPane, when fitToWidth is true, automatically
> adjusts its pref width to match that of its content? That would seem
> to be the "right" thing to do in this case, but I don't know that it
> does (or that it makes sense in all cases?).

ScrollPane.fitToWidth resizes its content (if resizable) to its viewport 
width. Does nothing if content is not resizable, and does not seem to 
change ScrollPane.prefWidth. I'd say "fit-to-width" could mean both: 
"fit content to viewport width" and "fit viewport width to content". The 
former is already implemented, of course. No horizontal scrollbar in 
either case.

> So it seems to me that there are at least 2 different ways we could
> go about supporting this specific use case, one seems like a
> straightforward thing (let -1 have meaning for prefViewportWidth) and
> one is the result of a perhaps questionable interpretation
> (fitToWidth=true changes the way we compute the prefWidth of the
> ScrollPane). Both seem reasonable ways to have tried to use the
> control and both yield unexpected results it sounds like.

The binding was not really obvious to me but eventually I arrived here 
and it would be nice to have this working. Additional API would make 
this easier to find but it might be hard to come up with something which 
makes sense in the API and does not change or conflict with existing API.

Werner


More information about the openjfx-dev mailing list