Last time I used Scenic View JFoenix Badges were refusing to show the expected styles. Until now I don't really understand why their JFoenix styles are not part of the library and by default loaded. But as I said before, I have only very limited experience with JavaFX. Maybe it's a common procedure to get hold of the css files and load them explicitly.

@zealous Its recommended for custom controls in JavaFX to declare their css using

UserAgentStylesheet

But a dynamic call to the method is discouraged.

@zealous I think it would help you out a lot. You'd be able to expand a TreeCell and check out the Label, making sure that your style was applied. If not, you might try a user defined style class just to get something working.

@carlw @abhinay thanks for your help. I will try to get a better understanding of the issue tomorrow using Scenic View.

@melston I added the

customitem

builder, and also an example on your PR: https://github.com/edvin/tornadofx/pull/488

It's already getting painful to push changes between the two branches due to structural differences. Doing it manually for now but we need a better strategy for sure.

@edvin Let's try a maven profile + different modules with different source settings then.

@carlw It's not that easy. You're welcome to try, but I don't think it will work. Can't really articulate why right now, need to get my head on straight after the trip and get some sleep first 🙂

i did it with javafx 2.2 / 8. i know your point about the kotlin files and packages being more open

i'll blog about a javafx 8/9 setup and you can look it over and see if it's suitable for kotlin + tornadofx

@carlw One of them is module based, the other not. There are already also files that must be merged with some logic as well. Maybe I was too fast with this JDK9 branch. We might need to redo after finding a viable solution to this.

@edvin you might need to scrap the branch to avoid a painful merge. but you at least got a good idea of the scope of the effort.

@edvin, thanks for the changes. There were a few things I wasn't aware of that you took care of.

@carlw Yeah, no big deal I guess. It was a good exercise to gain some understanding 🙂

@melston I just woke up and realized that my example on the PR was bad, it should have included an

action

for the customitem itself 🙂 Updating now.

I'm going to work on a 4 module blog post w. profiles if i don't get pulled into something else

@carlw Great! Between that and the experiences I had with the jdk9 branch I'm sure we'll figure out a good way to deal with this!

Good night 🙂

night

@edvin This experiment has all the code in one source tree under one Maven project. It's a little awkward toggling between the two configurations in IntelliJ. Maven works fine with each JDK as a separate profile within the project.

Here's the JDK 8 version. In IntelliJ, the project JDK is 8 and the jdk8 source folder is tagged as source (and the jdk9 source folder is not). Then, I use a run configuration based on JDK 8.

JDK8

JDK9

the JDK 9 configuration has the project JDK set to 9 and the jdk 9 source folder is tagged as source (jdk8 is not). The run configuration is based on JDK9

@carlw uploaded a file: fx-project-multiversion.zip

java/src/main would contain any code that would compile against both jdk8 and 9. jdk8 contains code that compiles against 8. same w. 9

I'm going to experiment with multiple modules which is what would avoid having to tweak so many settings while switching back and forth. In IntelliJ, you can specify JDKs on a per-module basis. there would be 3 subprojects: common, jdk8, and jdk9. common, depending on the profile, would have a dependency on the jdk8 module or the jdk9 module

@edvin this version looks more promising. no profiles, just two sibling modules: -jdk8 and -jdk9. The common code is stored with the parent where it isn't compiled. I have the project JDK set to 9 and was using a special run configuration ('clean install') to compile the JDK 8 distro.