Yeah, that makes a huge difference.

@edvin I'm getting used to plusAssign() however

I believe the main thing I have done is adding operators and chaining methods

I like to convert kotlin that is written in the language Kotlin to code that is written in the mindset Kotlin, but I don't think I like converting halfway that much...

yeah. and that's why these PRs are so helpful. i'm coming from the JavaFX side and carry a lot of baggage

I think we need a styleguide...

In that way we can have big discussions about what we like and don't like now and later refer back to the guide

or at least some rules. On this moment that would be the plusAssign for example, when use them and when not. If it's up to me, it's use all the kotlin operators and in the way kotlin likes them, but when we have a discussion about it and note what's comming out of it, I have something to stick to in this project.

(the rules don't have to apply to everyone, but at least to me, cause I will keep refactoring the code)

@tieskedh do you blog at all? maybe some of your pre-merge PRs would be good topics because you could talk about the specific Kotlin syntax and the place in JavaFX/TornadoFX. Plus you'll get a bunch of hits

I will take the time tomorrow to give my standpoint. I really like to change a lot of the current functions, but I just don't know if I will offend people with it, so I leave a lot of the formatting like it is now. For me is for example the length of the line a part that I want to change (by for example adding breaks in the parameters of functions, , but it's possible you love the long lines...

@carlw nope

@tieskedh not looking for long lines, more for understanding and adoption

@carlw I know, but that's one thing that triggers me a bit. And of course that we don't have any packages, but I guess that's because we can't use extension-functions in other packages that well, because it then will not be autocompleted...

@carlw where you are looking for is when to use `let /`run`/`apply`/`also` and about things like `takeIf`/`takeUnless` but also things like

when

?

yeah. and i'm interested to see these added. things like whenVisible might be incorporated into a more general scheme

I think you should try to collect the things about the framework, because I don't know lot about the framework. (to be honest, I haven't even tried it yet 😑

I'll do that when everything is refactored, so when the job why I started is completed

sounds like a plan. you'll get some insight about where developers are adding things like Nodes and handlers and how the apps are wired up (by inject(), etc)

yep, for now you are the framework expert and I'm the Kotlin-expert 😉

I'm now reall going to sleep. but i made a beginning https://stackedit.io/editor#!provider=couchdb&id=8LEuPZZBhXNTancew6NlAymu Isomehow want to be able to add reasoning for the choices later. pls, don't change the code...

are there any examples of using the three finger swipe back for back in tornadoFx?

@tieskedh Styleguide is a very good idea!

@pike I don't think so, but it should be exactly the same as in JavaFX, but you can use the

replaceWith

function together with a slide animation to go back.

Haven't done this in javafx yet either 😛

@edvin yep, and when we put a lot of arguments in it, maybe others will copy it. I searched on styleguide kotlin, but I didn't find a lot yet. I found one example that was not ready and Another one I use a bit as comparison, but they do "stupid" things. They for example reversed my rule of naming in nested also/let. The reason why I wrote the exact opposite is because you are much closer to the place where the it is defined and in the most part you are explicit.

Yeah. I like it so far, @tieskedh!

@pike Me neither I'm afraid 🙂

When I hava a label bound to a property such as label(model.name) it is simply changed when my model changes. But how would I deal with the problem when I constuct a text of multiple variables such as label(mode.firstName.value +” ” + modelLastName.value) as a best practice?

Do I need to create a new local property and use model.itemProperty.onChange to recreate the String every time or is there a simpler solution?