If there’d be interest in this idea, please do let...

# tornadofx

[mikehearn]

If there’d be interest in this idea, please do let me know. TornadoFX is abandoned but I’m starting to look around for a new project, and I have a fondness for JavaFX - ultimately, despite its neglect, the base engineering was very good. Jetpack Compose doesn’t quite seem right to me, partly because it’s a mobile toolkit (not so great for building complex database backed enterprise apps with lots of forms and charts), and partly because the whole attempt to make GUI “functional” seems wrong - a GUI is at heart mutable state. It’s the way the user mutates the state of your app. Trying to make something fundamentally mutable look and feel immutable seems like a square peg/round hole problem.

[melatonina]

I'm not particularly interested, sincerely, but thanks for the offer. I got accustomed to writing the bindings with just the helper functions, at this point.
I would enjoy more helpers to deal with null values more elegantly. I wrote some myself, but I'm just doing bare minimum to cover the cases that I come across. I think that in general that's something that people who wish to use JavaFX with Kotlin would find useful.
One thing where I think that the DSL makes sense is for the CSS. An interesting project would be a plugin that generates the DSL from the JavaFX documentation page with all CSS classes for any specific version of JavaFX.
It's probably possible to use a compiler plugin to detect expressions like:

bind {
    a = "total = ${b + c.d} €" 
}

and rewrite them as bindings of aProperty, bProperty, cProperty and dProperty, if a, b, c, and d are Kotlin properties delegated to those JavaFx properties, without the need of changes to JavaFx.

[mikehearn]

It could be done that way, but would then be Kotlin specific. Simpler and more portable to maintain a modified JavaFX. But yes, that’s the gist of the idea - re-run the lambda when a property that was referenced inside it changes.

[mikehearn]

Generating the DSL from the docs is definitely something I’ve already looked at. Dokka has a plugins interface that’d be suitable for that. It’d mean third party libraries become a part of the DSL too.

[melatonina]

What I meant is that you would emit "normal" binding code, and c.d would cause the compiler plugin to generate cProperty.select { it.dProperty } or even just the equivalent JavaFx select statement, since the types would be already checked at that point. There is no need to re-evaluate anything, outside of what JavaFx already does.
They are two different approaches, each with its merits.

[mikehearn]

Yeah, I understand.

[mikehearn]

BTW, can I ask why you’re using JavaFX?

[melatonina]

I'm prototyping a moderately complex Android application and its supporting service. I thought it would go faster if I could disregard much of the communication layers by developing a desktop version, first, and I also would get a "control panel" for the supporting service, as by-product.
Obviously I wanted to share as much code as possible with the Android application, so I wanted to stay all-Kotlin and ended up using JavaFx as GUI toolkit.
The operation has had relevant costs, but I still don't see a better choice and I'm reaching the other end of the tunnel, so I don't regret much the choice.

[mikehearn]

Fair enough.