@ron Yes, because setting it to the deploy phase fails when I deploy (it happens too late) so I have to change it to the install phase every time I push a new version to maven central. It sucks.

Did I forget to change it back again?

This FXML stuff just feels like too much duct tape. Going to revert it for now.

in fxlauncher its on the install phase so my my first "mvn clean install" fails

well you could give me your gpg key 😬

Hehe 🙂

hmmz and why does it have an empty .gitignore 🙂 ?

Just ignore it 🙂

sorry fixing it

(there is a great plugin for that)

Hehe 🙂

I'm taking the night off. Will revert the FXML stuff properly and think about a possible way to change the current FXML support, but I think the conclusion will be that we need a custom loader.

It looks like the existing one is 3,000 lines. I don't think you have to support the full FXML spec (yet) since Scene Builder doesn't let you define everything.

@edvin I'd also like to test custom FXML components too

It's also multiple support files. But written in Kotlin and by employing some neat tricks, it doesn't have to be so huge. If there are stuff we can skip as well, it might not be so bad. I think we'll revert first, then get a release together and then we could start looking at it.

@carlw what's custom FXML components?

Making sure that a custom component referenced in the fxml works. Not a standard one like TextField

Ah, of course :)

@edvin the ignoressl flag I am introducing I am not going to put that in the app.xml do you agree?

Just a command line argument

@ron Yeah, let's start with that.

@carlw I'm reverting all the changes I made to the FXML loading for now, since it doesn't offer much of an advantage, and there might be other issues than the one you found (#actions)

@edvin you can use FXML effectively in tornadofx today. If you break up your app into FXML, you just have to load them all separately and apply the Fragment() in a type safe builder declaration

@edvin Maybe we can start on a TornadoFXMLLoader feature branch? I think this class would be self-contained and the only effect it would have on the framework would be for things like an include() typesafebuilder or adding things that no one requested yet. but when the requests come in, then this class could be extended to consider those as well

@carlw Yeah, that's right. I didn't even think about that. I think we should suggest that to the guy who created the github issue for now, and say that we'll start working on a custom loader soon. Yeah, I think the loader could be separate, but I doubt anyone else will ever use it, so it might be easier to maintain by including it in core once it's complete.

Delivering Alyssa to Jiu Jitsu and trying out a new car, back in a bit!

@edvin ok. maybe work on a branch in my fork or we can add a branch to the main project?

@hastebrot I missed your maps comment yesterday. What do you think of Gluon's map offering? I have used it in a small project and it was ok. I know that there is also GMapsFX, but I haven't used that one.

In the past I had used https://github.com/msteiger/jxmapviewer2.

Gluon Map Component - https://github.com/gluonhq/maps