That would be pretty cool

And probably a pain in the butt 🙂

Oh yes 🙂

This Android news is great for TornadoFX. Earlier this week, I was pitching TornadoFX to a plain JavaFX client. It's an uphill battle mainly because of FUD, but the message of harmonizing mobile projects with desktop development resonated with them.

That's a good point. This gives us a little extra weight actually.

@kastork I figured out what's causing the double unDock callback. The removal from the Workspace results in both a change to the root.parent and the root.scene. This results in two callbacks. I made sure those callbacks are only sent when the docked state indicates they are needed. I.e a call to undock will only be sent if we are currently docked and vise versa.

The fixes these last days have been subtle, and frankly very nice to finally crack. But I'm worried about releasing so shortly after implementing them.

Travis reports that the current build is failing, but it's due to some network issue between GAE and Maven Central it seems. Downloads takes forever.

Actually, it is jcenter.bintray.com which is slow.

I'm changing the travis config so that it will cache .m2 between each build.

I just removed the experimental warning from

Workspace

. It seems pretty solid and I doubt there will be need for breaking changes.

I'm adding an

activeProperty

to

ListMenu

.

If any of you guys have a chance to test your apps with HEAD, I would be very grateful. Hopefully I did the last of the subtle changes today 🙂

Working on a screencast. Every time I do, I need a new feature.

I just added overloaded

imageview

builders that accepts observable strings and images. Very handy for usage in ListView and TableView.

That will actually be really useful for a project I've been messing around with lately.

@edvin I will test HEAD asp..

Working on my presentation right now and trying to come up with a way visualize the

TornadoFx-Layer

Not sure yet if I will just remove the slide and just have bullet points

@nimakro What do you think about a Kotlin layer between tornadofx and JavaFX?

@nimakro That's an interesting visualization. Wonder how it would look if it was complete! hehe

@carlw Good call! Kotlin is an important part of the puzzle.

yeah, i know that tornadofx is more than just java language bindings, but i don't think there's any actual java code in Tornadofx, right? @edvin

@carlw No, not a single functional piece of Java code. There are two classes, one is for a test and the other is to satisfy the Javadoc plugin which is needed to publish to maven central.

i think some of your tornadofx offshoots were experimenting with this like auto complete as a standalone javafx component

@nimakro you might also want to expose the JDK to the TornadoFX layer (through the proposed Kotlin layer) because there's some non-JavaFX calls that are made (Localtime, etc)

@edvin @carlw Thanks yeah that's right I think I will add the kotlin layer and remove the java layer

I will also remove the JVM layer so I have a bit more space

Yeah, the JVM layer is implied anyway.

it's tough to get these things completely orthogonal. after all, Kotlin is just a JAR, right? I'd opt for a general Java to include JRE + API since i think you're going more for logical + functional structures rather than processes