@Ruckus Thanks for the thorough explanation. I think we will run across developers that don't yet know that there technically would be no difference between

Date

and

Date?

for a

Property

, and others that know and care about it from a semantic standpoint. You might also use a class from a Kotlin lib that is defined this way, so you can't change it. There are some good reasons to support it IMO, and it might help to solve confusion as to why one can't use bind with those properties. I remember I actually ran into it myself early on. For these reasons I think we should support this both here and in other places if we come across it in the future. What do you think?

@Ruckus Do you know of any other places we would need to adapt for this if we accept the PR?

I just had an idea.. The plugin should have a "snippets browser", an integrated tab with a treeview of self contained samples that can be inserted into the current editor, or created as new file. We could add lots of small nuggets to make it easy to get started, but also boiler plate you could use in your day to day programming. What do you guys think?

The snippets could be automatically pulled from GitHub so it would be super easy for everyone to contribute.

I have a slight correction to what I said earlier. It seems

var value by someProperty

is

Type?

when

someProperty

is

Property<Type?>

, but is actually

Type!

when

someProperty

is

Property<Type>

.

The same holds true for

someProperty.value

(nullable if specifically declared, otherwise platform type).

This is actually preferable as it gives the user a route to assume the property is not nullable if it cannot be in their code, or force anyone who uses their code to treat it as null.

With that in mind, I think this PR is a rather good idea.

The only other place it looks like we'll need to handle this at the moment is in the

bind

function for

ViewModel

(and the

property

function to go along with it). Since the code change will be pretty much the exact same, I'll ask Jonathan if he can make the change as part of his PR.

@Ruckus Perfect! 🙂

@edvin I assume you are talking about Idea IDE… you could simply supply a set of 'live templates’ instead of snippets.

They are very easy to use and developers are used to them. Just an idea 🙂

@eryzhikov Yeah, maybe I'm over thinking it 🙂 But the "discoverability" of the live templates are a bit lower than a browsable menu perhaps. I haven't checked, but I guess it's possible to supply live templates via a plugin?

We always supplied them as a downloadable jar, but I would guess there should be an extension point. Yes, discoverability is lower, but from the other point of view devs are using them all the time so plugin just have to mention it

Here is what we did for FX properties (Java)

@User uploaded a file:

Cool thing about this approach is that it lets you provide “variables” which users can name themselves. This works as a sort of refactoring in-place

Yeah, that's right 🙂 Maybe I can even combine the two approaches actually.. Thanks for the input, I will play with live templates as well and see what works best!

If there are any FXLauncher users here, this might be of interest 🙂

@edvin sorry I didn't get to the guide this weekend. O'Reilly webcast prep for Wednesday is keeping me busy. I'll reengage shortly after that. This year is teaching me to master time management.

I did get around to an RxJavaFX release. Took an hour to implement my solution for the CompositeObservable, and I think I now have a full solution for UI/Model code separation.

I will have to try that launcher one of these days, I read the README.md and i remember having some questions about it. The program I wanted to use it for I decided to completely rewrite, I learned kotlin and javafx in that program 🙂

@thomasnield No need to apologize, we all need to do what needs to be done 🙂 I'm back on track from today btw, so I'll start cleaning up loose ends for the 1.5.6 release and write the OSGI example @ron asked for.

@ron Cool! I would suggest you use Gradle if that's an option, the setup is much easier there since we have the Gradle plugin. No big deal with Maven either, you basically just copy the stuff from the pom and you're set though.

@Ruckus Hmm.. Maybe I was a bit quick to merge the

KotlinObjectProperty

PR. Without a default value you could still get an NPE if you try to extract the value before it is set, correct?

@ron I'm still a little unclear about what you want to see in the OSGI chapter. There are support for tree automatically handled TornadoFX artifacts: Applications, Views and Stylesheets. They are all covered in the guide already. If I understood you correctly you wanted to see an example of how to create one bundle with an application and one bundle that contributes a View to that application, right? I feel like this is covered, so I need some more help to understand what you're after, sorry 🙂

when I am home tonight I will try to describe it better

@ron Great, thanks. Sorry for beeing a bit dense here 🙂

no problem

@jonathan I realize my implementation isn't good enough yet, but when I have polished the

SmartResize.POLICY

for

TableView

- do you think this would be a good fit for ControlsFX?