Should be fun.

Thanks for the pointers above

I can't comment until I try it out but will make a note.

I'm making some improvements to the default rest client engine. It turns out that if an http call returns a status code deemed an error, then the response is not available in

connection.inputStream

but rather

connection.errorStream

. The guys that made this API didn't do a very good job. Happy we're finally getting a new http client in Java 9!

Important notice: The

field

builder used to operate on the

inputContainer

inside the

Field

. This has been changed so that it now operates on the field itself. If you did something like

parent.isVisible = false

to hide the field, you must now change your code to

isVisible = false

. This new behavior is more as one would expect and hopefully the change won't cause any trouble to anyone.

I just added a small notice to the changelog:

@chris-hatton @edvin I have just a very little experience with JavaFX from Java and Groovy with Scene builder. I discovered Kotlin and TornadoFX about two weeks ago -- I'm never going back, though I imagine I'll have some struggles with team-mates who think it is impossible to build a GUI without something like Matisse or Scene Builder.

@chris-hatton @edvin TornadoFX to me is for the desktop what Vue.js is for the browser.

i wonder how hard it is to adapt Scene Builder to load/parse tornadofx kotlin rather than fxml

you can at any rate use FXML with TornadoFX

@mikehearn I'm counting on that to ease the resistance

But (so far, at least) I like the builders. Graphical UI tools make you keep too many wiring details in your head.

@mikehearn That's an interesting thought. I wouldn't think there would be any abstraction in scene builder to make that possible though. A new tool would be probably be a huge undertaking, but also an interesting challenge. I have an idea about how to do this actually, been playing with the thought many times.

i'm not actually sure where the scene builder source code is

gluon don't seem to have it in a github repository.

@mikehearn it's on bitbucket

ah ha

@edvin makes me think of groovy XML builders -- you could make FXML with one, I suppose... But I never thought of going from XML to builder syntax

it doesn't seem to be actively maintained.

On the plus side, FXML hasn't changed much so today's .fxml files are compatible with the Oracle Scene Builder from 2012

That's the issue. I think TornadoFX could get a huge boost from providing a better UI builder tool.

you could probably do it with XSLT transforms

The rendering of the UI isn't hard, since you can just "execute" the builder code and get a node back. Drop that in the center of a borderpane and add tools around it. Use a layer like we do in the LayoutDebugger to access nodes, change properties on them etc.

Just need to find a bullet proof way of mapping a builder statement to the actual displayed UI node. This would sure be interesting to play with.

Since the builder code executes, it could add cues and maintain the needed references pretty easily.

We also investigated modifying FXMLLoader to accept Kotlin controller classes. https://github.com/edvin/tornadofx/issues/179

I'd like to see something like this too. It could apply more generally to building code from graphical tools.

@edvin i think the gaps are nested views (fx:include), Kotlin controller classes, and FXML-packaged custom controls?

@edvin Scene Builder provides a lot of functionality. I'm not sure it makes sense to try and compete with it, vs patch it.