On 1/17/19 12:55 PM, Siddhesh Rane wrote:
January 16, 2019 11:31 PM, "Ty Young" <youngty1...@gmail.com> wrote:
How else is percentage based UI sizing besides DoubleBinding(s)? Isn't column
restraints just the
same thing but aligns everything to a column?
I have to ask(again) as to why minWidth/maxWidth, minHeight/maxHeight,
prefWidth/prefHeight aren't
read only if this is going to be an *always* realistically going to be an issue.
Column constraints don't use any bindings, neither do any other layout panes.
{min,pref,max} width/height are merely hints for a parent to layout the child.
They are not the final authority on child size. The actual final size of a
child is set by calling Node#resize on it, which is what the parent does during
the Parent#layoutChildren call. During this call the parent knows about its own
size and can split that space among the children.
A rogue parent could completely ignore these hints and resize the child to
whatever it wants.
The documentation on the sizing says that they override the computed size.
On your second point, it is only an issue if you use it in the wrong way,
without understanding.
Excuse me? There is no documentation AFAIK stating that this would ever
be an issue nor would anyone look at the UI and think that a GridPane is
necessary to achieve such a basic layout. The use of GridPane seems more
like a hacky workaround for something JavaFX seemingly has no other way
to achieve with more appropriate layout management nodes(VBox, HBox,
etc) without side affects.
I wanted to place the buttons and Scrollpane in a horizontal fashion, so
I used an HBox. I wanted to dynamically size the nodes based on a
percentage of the window's total width/height, so I used property
bindings to force content to the desired correct. If that causes issues
then maybe all controls should get a supported percentage based way to
set the width/height like GridPane's columns with appropriate layout
nodes so people don't try doing this sort of thing.
You bound the minWidth of a scrollpane's content to 85% of the scrollpane's
widthProperty (which is actual width).
When you resize the scrollpane to <85% of its original size, its content still
has the old minWidth property which is greater than the current width of the
scroll pane. So the scrollpane shows horizontal bar. This is not a bug.
widthProperty is supposed to be valid after layout.
This explains the ScrollPane horizontal scrollbar glitching out but
doesn't explain TableView's horizontal scrollbar.
Use bindings for size if you want to do some advanced sizing. Like size
matching unrelated nodes with different parents to get some visual effect. You
could create a custom textarea that binds minWidth to the number of characters
in the first line.
I have never had a use case but someone else might.
Use it for cases where there is no mutual dependency or "race condition".
I saw your code and I can confirm this is the main cause.
If you want a 15-85 % split, you should have used a GridPane with two columns
with the given
percentage constraints.
This works for the buttons/scrollpane but what about the subcontent?
TableView's scrollbars also
glitch out in the exact same way.
Set scrollpane to fit to width. Add a gridpane with a single column whose
column width is set to 85%. Set gridpane alignment to center. Drop the bindings
and your problems will be solved.
It isn't completely solved but it is better I guess. ScrollPane's
horizontal bar no longer glitches out and resizing performance has
increased majorly. TableView still glitches out from time to time and
app content is still jumping all over the place. Bindings are still
needed for the size of the main GridPane and other misc nodes. It seems
to be a bug caused by indirect resizing of the table itself...
And the vertical scrollpane bar is missing from the Overview content.
Setting the show policy to Always shows it being there where it should
be and is usable(regardless of policy) via scroll wheel. No other
section has this issue.
Font rendering is also still an issue...
SceneBuilder's lack of UI snapping compared to Netbean's Swing builder makes it
incredibly
difficult to get anything remotely pixel perfect without banging your head
against a wall. Separate
controller classes and FXML annotations everywhere isn't really desirable
either. I originally
entertained the idea of doing it all in FXML only to quickly discard the idea.
If you are talking about snapping like in aligning to other UI elements, then
its there and you dont need it with the rought layout. If you mean snapping to
pixels, JavaFX has it inbuilt and on by default.
It is but it is incomplete. Try resizing a Button in both SceneBuilder
and Netbean's Swing builder to the bottom right after first snapping to
the top left. The button will snap perfectly to both in the Swing
builder but not SceneBuilder.
Regards
Siddhesh
