that should go on the wiki

are there any examples yet on using dialogs the tornadoFX way?

@ron I will create documentation for the eventbus in the guide tonight, and then we can discuss changes etc 🙂

@ron Not really, but I think dialogs are described in the guide. I want to make something nice with the InternalWindow though, I feel the JavaFX interface is a bit clunky.

the internal window has to be in the stage, a normal modal can be shown even when the stage is hidden

I went through the guide, there does not seem to be anything related to dialogs

@ron I think the

alert

function creates dialogs, doesn't it? I'll make sure it's covered in the guide. We might need a better dialog builder though.

I was reading about fragments, apperently they can open as modal?

should check that out

@ron Yes they can 🙂

then I could send an FXEvent with the result of it

I use Fragments a lot since I use MDI, so there can be multiple instances of each View around the app, often in different windows.

I'm actually really excited about the new eventbus, it opens up a lot of opportunities!

I like eventbuses

they decouple so much

And you can send data as well, not just signals. The possibilities are endless 🙂

only disadvantage is that it is asynchronous

in my use case an external party sends a "associate me", the server will pull up a dialog asking confirmation and a name, then send back the name given by the user to the external party

@kojdecki has left the channel

@edvin - boy a lot happened while I was asleep! Will check the eventbus out today 🙂

If you pull the Platform.runLater() out of the publish() method and push it to the receiver, this class removes the dependency on JavaFX. This would let you run a bunch of non-JavaFX unit tests in a standard TravisCI image without trying to open a display.

@User uploaded a file: Notifications Class and commented: Can move runLater() to receiver to isolate JavaFX dependencies

I also have been using the publish() action to trigger a getter on the model. My class lets you pass arbitrary data, but I think it's a better pattern to do this 1. Initiate a model changing call (loadData) 2. Model throws event 3. Receiver receives event 4. Receiver queries model (type safe, maybe more than one call, etc) 5. Receiver displays view

@carlw We already require headless JavaFX support (and it works great) in our tests, and I'm not sure how I could "push it to the receiver" as you say - I want this to be handled by the framework, so if you have "configured" your events correctly, you don't need to care about what thread you're on, it will just work. That was my thought at least.

@edvin have you used travisci?

@carlw We use travis for the TornadoFX tests 🙂

@carlw Look at our travis config file here: https://github.com/edvin/tornadofx/blob/master/.travis.yml

Basically we do this:

@User uploaded a file: Untitled