I am installing 2016.3 again

when you compile tornadofx from the commandline with maven does it pick up the jvmTarget?

Yes, since it's part of the maven build it should.

ok I am officially stumped, I installed idea 2016.3 and it does not compile same error and some incident report to jetbrains

@edvin have you had a chance to look over my post from late yesterday?

@carlw can you do a test please?

you are on ubuntu? with oracle 8 jdk?

nvm sorted it

@edvin I needed to configure the compiler in keepassFX too

@carlw Sorry, I must have missed it? Which one was it?

@carlw Found it!

Don't know why I didn't catch that... checking it now!

link? I would like to read it too

back in a bit!

Pair programming again 🙂

I have some comments!

@carlw You cast to

Container

here instead of just adding the extension function to

Container

. That doesn't make any sense I think.

This:

@User uploaded a file: Untitled

Shoud be this:

@User uploaded a file: Untitled

@carlw Apart from that this was a very nice peek into both Kotlin and TornadoFX, and will help remove some mystique surrounding the builders. Great work!

@edvin Regarding the cast, I'm trying to make the extension function mimic what's done in TornadoFX. For example, label{} is not an extension function of VBox or HBox, but rather the superclass "Builder". This is the specific casting code that I'm copying... fun EventTarget.getChildList(): MutableList<Node>? = when (this) { is SplitPane -> items is ToolBar -> items is Pane -> children is Group -> children is HBox -> children is VBox -> children is Control -> if (skin is SkinBase<*>) (skin as SkinBase<*>).children else getChildrenReflectively() is Parent -> getChildrenReflectively() else -> null }

@carlw In your example,

buildPart

would generate a cast exception if it's called on a Part. If you change it to

Container

it won't be available on

Part

. That's an optimization you can do, that we don't have the luxury of.

Right, my example leaves off at the Container object while every TornadoFX builder can have its own op. I set out to explain the {} in the builders and how several child objects register themselves with their parent.

I think I understand your reasoning, but I'm afraid some might be confused by the cast and maybe even point out that you introduce the possibility for a cast exception at runtime. Not a big deal though 🙂

@edvin that's why i made sure to use fake names like Container and Part instead of HBox and Label. How is my casting different than what's in FX.kt?

There is a cast exception option there. I prefer the Container.buildPart from Edvin

@ron That makes the example cleaner, but it's not what is done in TornadoFX. Everything is an Extension Function of EventTarget (the Builder class in my example). It just so happens that when we call a label{}, it usually has a layout component like hbox{} as the receiver object (but as an EventTarget).