Add support for split panes about tornadofx HOT 19 CLOSED

I implemented it with two possible usage patterns.

1. Create the nodes for the splitpane up front:

val left = HBox()
val right = HBox()

splitpane(left, right) {
    setDividerPositions(0.3)
}

1. Add the items inside in a more "builder like" fashion:

splitpane {
    items {
        label("I'm on the left side")
        label("I'm on the right side")
    }
    orientation = HORIZONTAL
    setDividerPositions(0.3)
}

The two options can also be combined. It's possible to shoot yourself in the foot here, but with proper documentation it shouldn't be a problem :)

from tornadofx.

Works like a charm.
Here's a quick test I did (the basic layout of an app I'm converting from Java to try Kotlin and TornadoFX out):

class TestLayout : View() {
    override val root = VBox()

    init {
        with (root) {
            menubar {
                menu("File") { menuitem("Close") }
                menu("Edit") { menuitem("Delete") }
                menu("Help") { menuitem("About") }
            }
            splitpane {
                items {
                    stackpane { label("Left") }
                    stackpane { label("Middle") }
                    stackpane { label("Right") }
                }
                orientation = Orientation.HORIZONTAL
                setDividerPositions(0.3, 0.7)
                vboxConstraints { vGrow = Priority.ALWAYS }
            }
            hbox { label("Status") }
            prefHeight = 600.0
            prefWidth = 900.0
        }
    }
}

from tornadofx.

@t-boom wow, nice example :) You're getting the hang of this quick :)) As Thomas said, we appreciate all contributions, from filing issues to pull requests :)

from tornadofx.

It would make sense to add this. I'll take a look and see if I can add it.

from tornadofx.

Awesome. I would have tried committing a pull request, but I'm quite new to Kotlin and TornadoFX.

from tornadofx.

Shoot, SplitPane does not extend Pane which the builders target. From what I see we basically have to re-implement every builder for every control for SplitPane or use a fake Pane strategy. The problem with the latter approach is the closure would target a Pane and not allow access to the SplitPane's properties.

@edvin do any ideas immediately pop up to mind?

from tornadofx.

I'll give it a shot right now :)

from tornadofx.

I've thought of a couple of strategies, like multi-inheritance delegation, but Pane and SplitPane are classes and not interfaces unfortunately : (

from tornadofx.

There are some things we just can't do with extension functions, so maybe down the line we'll change the strategy for the builders and do like JetBrains did with Kara basically. For now, we should go with the same approach we use for the toolbar builder, to stay consistent.

from tornadofx.

Thinking out loud here... is it possible we can create an interface that holds all the builder functions as well as an abstract plusAssign(), and we can apply them to any type such as Pane and SplitPane? If that would work, we can scale this problem for other "Pane-like but not Pane" controls we may have not considered.

from tornadofx.

But I don't think that would work since extension functions can't be applied via interfaces. The target types need to be extended. Darn.

from tornadofx.

Haha you thought that through pretty well. I think that works!

from tornadofx.

You're right Thomas, that wouldn't work :( There are a few tradeoffs, but all in all builders are working quite good right now, so I think it's best to leave it like it is for now. Could you add a splitpane example to the docs?

from tornadofx.

The items thing is a trick we can use for stuff that doesn't extend pane etc. The good thing is that we could keep this for backwards compatibility even if we change the builder structure later.

from tornadofx.

I agree, you're right that is a better abstraction strategy. I'll add an example definitely.

from tornadofx.

Thanks Thomas!

@t-boom Let me know how the splitpane builders work for you :)

from tornadofx.

That is beautiful, thanks for making this request and test driving it. We will likely include it in the coming release probably with the cell factories for TableView.

I hope you are liking Kotlin and TornadoFX so far!

from tornadofx.

I'm loving them so far. Hopefully I'll be able to contribute more with experience.

By the way, you guys have possibly the best response time I've ever seen. Kudos 👍

from tornadofx.

No problem! @edvin would have beat me if it wasn't late in Norway. He started a great initiative and I'm excited it caught fire quickly. If you have any questions or suggestions, please let us know. We welcome help!

from tornadofx.