I was thinking yesterday people

(yes I do think 🙂 )

we know what tornadoFX does

but as more people start giving presentations about ti

what is the mission

That for sure has changed a lot. I'll blog about it soon as well.

is “lightweight javafx framework” enough?

@ron Maybe not anymore 🙂

I'll log off so I can consentrate. Back later!

@edvin did you see the earlier coroutines discussion?

oh that was a fun discussion, I wish you had been here

@carlw I saw it 🙂

@edvin seems like we might need to extend the task() in TornadoFX to pick up a suspend() and isSuspended()...this breaks from JavaFX which doesn't have those concepts

only if we want to support kotlinx.coroutines

We'll find a nice way to support it, I'm sure. Talk to you guys later!

I think it was a mistake to pass parameters to views using

vararg params: Pair<String, Any>

. It should have been

Map<String, Any>?

. I really want to break the API and fix this. It's nicer to use, and it makes it possible to use varargs for other things (which I have a need for to make Workspaces nicer). Hopefully not many people will have used it. If needed, we can release as

version 2.0.0

. What do you guys think?

that'd affect

by param()

?

@permalmberg Not the

by param()

usage, but the call site. So if you did

find<SomeView>("name" to "John")

you would have to change it to

find<SomeView>(mapOf("name" to "John"))

. For multiple parameters it's gets messy anyways, and you'd want to do:

find<SomeView>(myparams)

instead, which would be possible with this change.

(

myparams

would be a map you created before you called

find

)

yeah, that's what I meant 😛 Go for it. Makes the call cleaner.

Sweet. I'll see if others chime in over the weekend and change if we get a consensus on that it's acceptable.

personally I've jused it at six places, but changing them wouldn't bother me

@permalmberg Great. I don't think many people have started using it heavily anyways, so as long as we inform well about the change it should be a minor annoyance.

It'd be nice with an alternative to creating a map though, like findWithParam<>( "name", instance)` Perhaps for up to three arguments? Not sure if that can fit in with what you have intended, but its worth mentioning....

@permalmberg Let me think about this, maybe we can do better as well. If we're going to break the API it might as well have a real benefit.

indeed

I've been working all day, so I'm going to watch some TV and think more about this tomorrow. Will report back if I get any wonderful ideas 🙂

Enjoy. And thanks for the effort you put into tfx. It is awesome

Thank you Per 🙂

@edvin I think the Map is better than the JavaFX Pair because it can flow from the model a little easier. If you're parameterizing a ComboBox, then maybe the Pair is fine. I could see a case where you'd like to go from a View to a the View with a data structure that might not be coming from a JavaFX source. The View is a substantial entry point.