Tornadofx: View doesn't get undocked when `dock` is called with scope.

[adam-arold]

I'm trying do dock a View into a Workspace but when I call dock onDock gets called on my View but onUndock doesn't get called in the old View so my screen stays the same. Steps to reproduce the problem:

fun main(args: Array<String>) {
    Application.launch(TestApp::class.java, *args)
}


class ParentScope : Scope() {
    val id = UUID.randomUUID().toString().substring(0, 4)
}

class ChildScope : Scope() {
    val id = UUID.randomUUID().toString().substring(0, 4)
}

class TestApp : App(Workspace::class) {

    override fun onBeforeShow(view: UIComponent) {
        workspace.dock<ParentView>(ParentScope())
    }
}

class ParentView : View("parent") {

    override val scope = super.scope as ParentScope

    override val root = hbox {
        button("new child") {
            action {
                workspace.dock<ChildView>(ChildScope())
            }
        }
    }

    override fun onDock() {
        logger.info("Docking parent (${scope.id})")
    }

    override fun onUndock() {
        logger.info("Undocking parent (${scope.id})")
    }

}

class ChildView : View("child") {

    override val scope = super.scope as ChildScope

    override val root = hbox {
        text("In child")
    }

    override fun onDock() {
        logger.info("Docking child (${scope.id})")
    }

    override fun onUndock() {
        logger.info("Undocking child (${scope.id})")
    }

}

Here if I click the new child Button I'll see the following in the log:

11:08:53.711 [JavaFX Application Thread] INFO  Test - Docking parent (29d6)
11:09:08.080 [JavaFX Application Thread] INFO  Test - Docking child (02f6)

So docking works but undocking doesn't. Am I doing something wrong?

[edvin]

If you look in the App class you'll see that it already defines a Scope, so the end effect of your code is that you dock the child view in a non viewable scope. The ParentView is therefor not displaced by the subsequent child docking operation, so the ParentView is never undocked. To configure the default scope for the initial workspace, use this approach instead:

```kotlin
class TestApp : WorkspaceApp(ParentView::class) {
init {
scope = ParentScope()
}
}
````

That's all you need to change to make your code run without issues. However, I realize that this is confusing, so I'll introduce a better way to override the default scope in the next version. That said, I'm not sure you really need to create specific sub classes of Scope. You should rather put the distinctive properties into a ViewModel and inject that into each Scope instead.

[edvin]

I'm committing a fix that will make any UIComponent docked in a Workspace assume that workspace into it's scope, so now you're initial code will work as well. However, the best way to define a custom initial scope will from now on be:

class TestApp : WorkspaceApp(ParentView::class) {
    override var scope: Scope = ParentScope()
}

[adam-arold]

I ended up using ViewModel and dockInNewScope(model) as you suggested, thanks! Should I close this? And thanks for the quick reply!

Btw are you still working on TornadoFX? I've heard that it got abandoned but I'm not sure.

[edvin]

That's probably better :) Thanks for reporting though, I got to clean up the scope handling :) Closing.

[adam-arold]

Btw are you still working on TornadoFX? I've heard that it got abandoned but I'm not sure.

[edvin]

Both me and a lot of others are working on TornadoFX, it's not abandoned at all. Where did you hear that? That said, I haven't been able to contribute as much as usual lately because I'm working on other projects, but I can assure you that TornadoFX is here to stay :)

[adam-arold]

I've read it on Reddit (/r/kotlin I think) but it did not make sense since I checked the GitHub repo and saw releases. Maybe they are confusing this with JavaFX. Thanks for the heads up!

[edvin]

OK, thanks :) JavaFX is not abandoned either, but rather it was set free :) Not having JavaFX as part of the JDK is a huge relief, because it means that we can iterate faster and it will be much easier to get fixes and features into it now :) We are working on a Java 11 compatible version of TornadoFX by the way!

[adam-arold]

Can you point me to some webpage where this is properly explained (the future of JavaFX)? I'm a bit confused about what the implications are.

[edvin]

Straight from the horse's mouth: https://blogs.oracle.com/java-platform-group/the-future-of-javafx-and-other-java-client-roadmap-updates

[adam-arold]

Into the rabbit hole, I go!