Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vertical Grow support for VBox Constraints #190

Closed
gtnarg opened this issue Oct 14, 2016 · 8 comments
Closed

Vertical Grow support for VBox Constraints #190

gtnarg opened this issue Oct 14, 2016 · 8 comments

Comments

@gtnarg
Copy link
Collaborator

gtnarg commented Oct 14, 2016

When using controls such as TextArea in a form, the form does not honor vertical growth as configured below:

form {
    fieldset { 
        field {
            textarea {
                vboxConstraints { Priority.ALWAYS }
            }
        }
    }
}
@edvin
Copy link
Owner

edvin commented Oct 14, 2016

The container for the textarea in the example above is an hbox, that's why the vboxConstraints have no effect. We will look for a way to express this by other means.

@edvin
Copy link
Owner

edvin commented Oct 15, 2016

By the way, for your example above to have any effect inside a VBox you need to specify the vGrow property:

vboxConstraints {
    vGrow = Priority.ALWAYS
}

@edvin
Copy link
Owner

edvin commented Jan 21, 2017

I've been thinking more about this. As mentioned, the field builder creates an HBox container and places all the children inside it. What if we introduced a verticalField that creates a VBox? That would place multiple inputs below each other, and also support vgrow. We could reuse the existing field builder and add a orentation to it, but the problem is that the op block would then need to operate on Pane instead of either HBox and VBox, so you would have to do a cast to access fillWidth, fillHeight and other properties of the boxes.

Another approach would be to create a new container called XBox, which has all the properties of HBox and VBox, and lays out its children according to the orientation. With this we could actually keep backwards compatibility. Not sure how hard it would be to do though.

This might be over thinking it, maybe it's better to change the op block to work on Pane instead. I can't see it breaking much (if any) existing code.

edvin pushed a commit that referenced this issue Jan 21, 2017
…ut container to be a VBox instead of an HBox (#190)
@edvin
Copy link
Owner

edvin commented Jan 21, 2017

I have added orientation as a parameter to each field, so you can now do:

form {
    fieldset { 
        field(orientation = VERTICAL) {
            textarea {
                vgrow = Priority.ALWAYS
            }
        }
    }
}

Is this satisfactory for you?

@gtnarg
Copy link
Collaborator Author

gtnarg commented Jan 22, 2017

The following only grows the bottom field when the window is resized:

import javafx.geometry.Orientation
import tornadofx.View
import tornadofx.*
import javafx.scene.layout.Priority

class Issue190 : View("My View") {

    override val root = form {
        fieldset("FieldSet") {
            field("Field 1") {
                textarea {
                    prefRowCount = 2
                    mnemonicTarget()
                    vgrow = Priority.ALWAYS
                }
            }

            field("Field 2", Orientation.VERTICAL) {
                textarea {
                    vgrow = Priority.ALWAYS
                }
            }
        }
    }
}

image

@edvin
Copy link
Owner

edvin commented Jan 22, 2017

Yes, because you didn't add the Orientation.VERTICAL parameter to the first field, so it's created as an HBox. Does that make sense?

@gtnarg
Copy link
Collaborator Author

gtnarg commented Jan 22, 2017

Doh! Makes perfect sense. Works great now :)

Thanks Edvin

@edvin
Copy link
Owner

edvin commented Jan 22, 2017

Great! Thanks for bringing this up :) It made the Form component much more versatile :)

@edvin edvin closed this as completed Jan 22, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants