yeah. i'm checking the Java version too

Sorry, I'm dense. "Yeah, it compiles" or "Yeah it doesn't compile"? 🙂

@carlw It wouldn't compile unless you pulled the latest TornadoFX, since I added this feature some hours ago.

works fine. Any Property will do

The first snippet should compile though.

Sweet!

the Kotlin compiles with 1.5.9 anyway b/c itemsProperty().bind is looking for a Property and not specifically an ObjectProperty

There is actually a case where the compiler cannot choose between them. Will fix now.

so, for @gtnarg you can wrap the ObservableList up in whatever Property you want: ObjectProperty, ListProperty. ListProperty seems to be better because it will add in ListExpression functions without having to de-reference. (ex, listProperty.isEmpty() versus objProperty.get().isEmpty())

It would work with

SimpleObjectProperty<ObservableList<Customer>>()

but not with

SimpleListProperty<Customer>

since that would match both versions.

Yeah, if you need those functions it's better. The generic signature is also much more pleasant to look at.

@edvin Could you add a static JVM directive to disambiguate the Property argument?

@carlw No, not even the Kotlin compiler can deal with it because of type erasure. What I can do is probably just add a specific version for SimpleListProperty that delegates to the correct one.

My theory is that adding something like this would solve it:

fun <T> EventTarget.listview(values: SimpleListProperty<T>, op: (ListView<T>.() -> Unit)? = null) = listview(values as ObservableValue<ObservableList<T>>, op)

Compiling, waiting... oh, the suspense!

I think that worked 🙂

Can you take a look at commit 208baf0c ? This won't work to have 2 different Java methods, one servicing ObjectProperty and one ListProperty?

That's right, if somebody wants to call them from Java they would have to be separated. Should we support them from Java? I'm not sure how usable this builder would be from Java.

(Haven't tried)

no, IMO only Kotlin is needed

Then I'll leave it. This was a very nice addition. I'll try to create a screencast about my use case for this tonight.

@edvin @gtnarg I'm going to move to ListProperty b/c of the extra functions in code like I posted earlier. This matches the docs fine because it's the Property bind() argument that we're discussing rather than the ObjectProperty setItems() argument on ListView

That's a good idea.

@edvin Why are you using SimpleListProperty instead of the interface?

@carlw Because I'm ignorant. Will update now!

Seems

ReadOnlyListProperty

would be the correct one.

Done. Thanks @carlw 🙂

I found a way to throw out a lot of the TableView column builders, reduce ambiguity and sweeten the syntax in a couple of places. Working on it now.

@edvin you are crazy... crazy good 🙂 thanks for all of this work...

@jchildress Thank you 🙂 TornadoFX is completely reliant on all the feedback and suggestions you guys provide right here.