@edvin just pushed it to GitHub, check it out!

Sweet!

Bayes... fun 🙂 We use it for spam prediction

@edvin I adapted the spam filter pattern for this purpose.

I'm going to use this demo app for KotlinConf... contingent I actually speak of course.

@thomasnield Sweet, hope you get it approved! Would love to hear it! I didn't submit anything, busy with CNC these days 🙂

@edvin no.... you still got time.

Okay

I'll just enjoy the show this year 🙂

@edvin It looks like I missed this memo. I understand why this fix was put in place. Had problems with the ambiguity before.

I'll see if I can help update the guide later.

@thomasnield Thanks, Thomas. This was very unfortunate, and I don't really like that the new name is so long, but I don't see any way around using another name for it.

@edvin what if you named it

column()

and

mutableColumn()

?

That seems much cleaner imo.

I am anecdotally inclined to think most things displayed in a TableView are a POJO or POKO.

@thomasnield I think that would give the wrong impression. That sounds more like I'm allowed to change the column, not that the column will be bound to a property.

@Ruckus that's not my first impression. What does everyone else think?

I'm going with no. My reasoning: I feel most people that use JavaFX are used to everything being properties, so the default

column

builder should function accordingly. TornadoFX adds simplified support for using POJOs and POKOs in tables, and since this is "new" functionality, it should have the clarifying name that specifies the difference. (This is just my opinion, and I would love to hear others's (I never figured out English rules for 's after plurals).)

How can you bind multiple selected items in a tableview with multiSelect enabled to a ListProperty or something similar?

bindSelected

works for me to bind to a single ItemViewModel but not for a SimpleListProperty.

TornadoFX got some mention at Holger Brandl's Frankfurt talk on Kotlin's data science ecosystem https://holgerbrandl.github.io/kotlin4ds_kotlin_night_frankfurt//emerging_kotlin_ds_ecosystem.html#56

I feel that in JavaFX, your domain objects should use observable properties, and in fact utilizing many of the features of JavaFX require observables. Therefor I feel that it's most natural to not add cruft to the default case, and keep

column

as is. Also, we don't want to break the API, and the support for immutable properties was added last, so it should be the one that needs to move IMO. Very unfortunate, but still.

@thomasnield I think you might be able to just add your own override, so you can keep calling it column. Will experiment with it as soon as I get time 🙂

Is there a guide to running testfx tests with tornadofx in headless mode?

Right now Travis is reporting the build as failed, but it's not a code error, it's because the apt-command to download JDK8 for the test failed.

hello! it's not about tornadofx which would have been a bit overkill, but i published a kotlin/javafx equivalent of react.js's tutorial app

you will all be pleased to hear that the kotlin/jfx version is about half the size of the reactjs version, in terms of lines of code

@mikehearn Nice! Coincidentally, I also made a TicTacToe game, not in TornadoFX. What is the world coming to...