@edvin Another question: Right now we don't support the `cellFragment`construct for the

TreeView

?

@nimakro I thought we did, but maybe I'm mistaken. Care to add it? 🙂

I will soon start looking at a way to make

TreeTableView

data driven btw.

@edvin Oky will look into

cellFragment

not sure, if I will find time to make a PR today though.

@nimakro No big deal. I might do a release tonight, with or without it 🙂 So much good stuff in this release, and I'm eager to get everbody going with jvmTarget 1.8.

Also making sure that

Node.findParentOfType

can find parent UIComponents as well as Node instances. Very handy in nested View situations where the parent might be a Fragment, so you can't do find<FragmentType> to find actual parent instance.

not just the treetableview, start with the treeview 🙂

I still have that java code somewhere that did that

OK

@edvin would you translate the java automcompletetextfield to kotlin? or just add the java and make the builders?

I am leaning towards rewriting it to kotlin

I think it's unfortunate when these great controls get buried in Kotlin - as they are great javafx features. I think it would be better to create them in java and provide a nice kotlin api around them - that way both worlds could benefit (and you might get some more converts just by exposure) - just a thought...

@gtnarg I agree. The implementation can be a bit tighter in Kotlin, and when we make it especially for TornadoFX, we can leverage support that is not in JavaFX core as well. We can also integrate the controls with the Workspace etc. That's why I feel it makes more sense to do a complete rewrite, and put it in tornadofx-controls for example.

It should be fairly easy to do at this stage though.

are you not saying the opposite of what grant is saying?

I agree that it's unfortunate that they get buried in Kotlin, but my approach to making them available to vanilla JavaFX is different, for the reasons mentioned 🙂

I don't think I can find the time to reimplement it myself, and I don't want TornadoFX to have a dependency on another Java library, but we could get the word out that it's fairly easy to port, and that a PR towards tornadofx-controls are most welcome 🙂

so autocompletetextfield would be in tornadofx-controls?

That's one possibility 🙂

@ron Wait a minute.. You're talking about a autocompletetextfield, but we only have an autocomplete combox, right?

What autocompletetextfield are you referring to?

I have code waiting to be adapted for autocompletetextfield

OK 🙂

I think I should it to you some time ago

@User uploaded a file:

Yeah, I remember that now, I just got confused because we've been working on the combobox lately.

@edvin - I'm not suggesting that the controls be in a separate library - I'm suggesting that they be built in java within tornadofx - on which the kotlin code could depend. tornadofx-controls could just be an extraction of the java classes and there would be nothing to port or keep in sync between the two projects.

@gtnarg That's something to think about. TornadoFX could potentially have a dependency on tornadofx-controls, and just provide the builder layer and specialized support on top of that.

It would mean that some of the controls need some extra hooks, but that's just positive and would make them more usable outside of TornadoFX as well.

hmmz then the tornadofx-controls would always be one of the must dependencies of tornadofx