Complete remaining missing builders

[eugenkiss]

Most of the (important) builders were created. However, some are still left to be finished. A good opportunity for a contributer :stuck_out_tongue_winking_eye:. The following files are concerned:

• [ ] Cell.kt
• [ ] Shape.kt
• [ ] Media.kt
• [ ] Transform.kt
• [ ] Effect.kt

[thomasnield]

I might be willing to help with this over the next few months. Are you still accepting PR's? What's the status of this project?

[eugenkiss]

I'm still accepting PRs. However, I've stopped working on the project since quite a long time. I think the last update was for Kotlin M13. Since Kotlin changed quite a bit since then and I had some time to think here's how I think the project should be changed:

• Kotlin now generates properties from Java getter/setters automatically. So a big part of the code generation scripts in this project should be obsolete. They should be removed.
• I think the kotlinfx.abbreviations package is not really needed. It should be removed.
• I would completely get rid of all Kalium things for now. As it stands, the implementation is too naive. A more fruitful approach would be working on a ReactFX integration (e.g. maybe some extension functions/wrappers, if actually needed).
• What's left and useful are kotlinfx.builders and kotlinfx.bindings. If I'd restart work again on KotlinFX I'd remove everything except these two packages/features. This way, the project becomes much slimmer yet will still bring advantages over pure JavaFX in Kotlin.

I'd be happy to transfer ownership of the project if anybody's interested.

[thomasnield]

Let me get my hands dirty in the coming weeks and see how helpful I can be. If I can contribute I don't mind helping out.

I agree on the Kalium thing. I've used ReactFX and later RxJava. Creating a reactive framework is hard and it makes sense to use an existing one. I actually spent some time last night getting RxJavaFX up and running. I'm waiting on Netflix folks to look at my PR.

Personally I like RxJava as a reactive framework because it supports thread scheduling whereas ReactFX keeps everything on the JavaFX thread. ReactFX is more popular at the moment so it might make sense to support that, although RxJavaFX is a very small API and probably will be trivial to implement, and we might even be able to copycat it in this project.

But I agree with all your points. Builders and bindings should be the real focus right now. Then ReactFX/RxJavaFX support later.

[thomasnield]

Correction: It looks like ReactFX has threadBridge so I stand corrected on my concurrency comments. But RxJava support would still be nice especially for those of us who do not design reactive libraries specifically for GUIs.

[orangy]

Is it possible you guys can come up to Kotlin Slack (http://kotlinslackin.herokuapp.com) to discuss and may be find people willing to pick up?

[hastebrot]

What's left and useful are kotlinfx.builders and kotlinfx.bindings. If I'd restart work again on KotlinFX I'd remove everything except these two packages/features.

:+1: This way we also easily get rid of some old code that depends on an older version of Kotiln.

[thomasnield]

@orangy will do : )

[eugenkiss]

@orangy, once I receive the invitation mail, I'll be there as well :+1: .

[thomasnield]

Hey has anyone looked at TornadoFX? It looks like it has Kotlin builders too?