I’m in New Zealand

9:44am on Monday

Okay, cool. I try to keep track of who is when. I'm in Utah, US (15:45 Sunday here)

@edvin: For the view transitions, do you think it would be worth it to make them work on any node, with special support for

UIComponent

? It would make it easy to use any transition in your grid view, not just card flip.

I'll do some tests with it tomorrow or Tuesday (I'm not sure if I'll have time between all my meetings tomorrow) and see if it causes many issues.

Texas here, 5:14pm Sunday

Welcome @frosch95 !

From JavaFX Links of the week

I have to somewhat consider what @jonathan said the more I think about it. This is a useful utility that might belong in ControlsFX. The sucky part is there is no extension functions in Java, and you would have to use a

TableViewUtils

static utility class or something to do something like this.:

Moving into openjfx will require the removal of all external dependencies

so moving away from TornadoFX is step one

@User uploaded a file: Untitled

moving into ControlsFX is a good way to deal with this - because ControlsFX doesn’t have external dependencies

Yeah, and the proposed API usage would look something like above

but understanding how a utility method like this should be mapped into public API is also part of the fun challenge

I would wonder in this case if the functionality to be wrapped into a tableview row factory, for example

I'll defer to @edvin on what he wants to do. I doubt we are going to want to maintain this in both TornadoFX and ControlsFX. But if the utility is mature enough then we could port it over to Java with little concern about maintenance.

Here is the source code in Kotlin

We also broke ground for the

tornadofx-controlsfx

project.

So we could bridge it to TornadoFX using that. I'll be upfront and say we will likely be biased to prototyping things in Kotlin because its tactical and easy to change. But I don't see many problems in migrating something over to ControlsFX/openjfx once it matures, except for one: we need to plan on deprecation cycles and phasing those functionalities out of TornadoFX in a controlled way.

From my perspective it is entirely up to you how to proceed - you shouldn’t even feel pressured to leave Kotlin if you don’t want. It is just your call if you want to work on things destined for OpenJFX or if you want to focus on your Kotlin approach.

Again, I'll defer to @edvin on what he thinks is best. We love the tools we build and the cohesion Kotlin and TornadoFX allows, but we definitely want to contribute to OpenJFX.

I just saw you guys talking about TableView improvements, and I’m always keen to recruit others to do some open source contributions

Haha absolutely, and that's why we jumped onboard! Just realizing there is more planning involved and we need to account for...

OpenJFX moves at a very slow pace

we won’t take lots of submissions, especially for JDK 9 updates releases

but we can take some small, targeted improvements if they are ready