Or alternatively load an image from the classpath: Best I could come up with is that:

graphic = FX::class.java.getResource("/com/cedarsoft/.../busy.gif").toURI()

I have a gradle project for my JavaFx application

How do i generate native bundles using IDEA

I tried doing it from the project structure but the application doesn't seem to run

Is there any guide to it ?

Hey guys. Could one give me a hint how "finally" could be done using runAsync? At the moment I am adding .ui{} and .fail{} which is not so nice...

@jschneider I always work with ui + fail or the JavaFX equivalents succeeded/cancelled/failed. If you want to try something novel to run in both succeeded and failed conditions, you could bind to both properties as an or() expression

...that is, add a listener that listens to the composite expression

@Ruckus Yeah, you're probably right. In this case I wouldn't even bother with caching the cell content, but I wonder why it fails. Will investigate!

@plebian You'd have to listen to changes in your properties and refresh manually. It would be too resource consuming for the framework to do this by default.

@jschneider You're right, there was a "cleanup" run a while back where we changed to the shorted syntax where possible - and apparently where it wasn't actually possible 🙂 Updating now 🙂

It should also be

enableWhen(model.valid)

Fixed.

@g4sarma I didn't know IDEA could help you with native bundles. What you want is to run

javapackager

, see docs here: https://docs.oracle.com/javase/8/docs/technotes/tools/unix/javapackager.html

@jschneider I don't think FontAwesomeFX lends itself to css manipulation. I've been wanting to create a version that supports this, but time doesn't permit atm.

does tornadofx have it's own canvas, like

java.awt.Canvas

(my googling didn't turn up anything other than KotlinJS HTML canvas stuff)? or should we just use that (java.awt) library? to clarify: just wanting a class that facilitates drawing shapes and images onto a pane, really

A threading question: I have a model (with properties) that is edited using an ItemViewModel. After calling commit, I'd like to store that object using a REST call. Of course that REST call should happen in a background thread. What is the best practice to get the values into the background thread without any issues? I am looking at the source code of the github-browser and can't quite get it. The "controller.GitHub#listIssues" method is called from runAsync{} but accesses properties of the UserModel which are JavaFX properties -> I think that might be problematic?

@jschneider I think you can read JavaFX properties off of the UI thread 🙂

@edvin Well, you could run into some crazy race conditions, but as long as you are only reading, it should be ok in (most) cases. Theoretically the background thread could be delayed. When accessing the properties later, they might have been changed already.

Yeah, I guess it depends on your use and requirements, but it shouldn't throw any exceptions at least 🙂

@jschneider you shouldn't be doing any UI manipulation in the async. part of the call. Everything passed to the Task/Thread should be final or effectively final. I think the only trouble you can get into with properties is manipulating them and having their listeners fire off the FX Thread

@carlw of course - no ui manipulation. I am talking about that scenario: UI: set property to "foo", call runAsync() Worker-Thread: Waiting for whatever (thread becomes available) or something. (will not happen in most real live scenarios, but is theoretically possible) UI: Continues work and changes the property to "bar" Worker-Thread: Finally starts running: Reads the property --> gets "bar" So theoretically, the UI thread should copy the values to final fields and the worker thread should only access these

@jschneider this sounds a little like a case for coroutines for me. i think you may want to involve nested Tasks. The first Worker-Thread has a succeed (ui) method that spawns the second Worker-Thread. The second "UI:" is manipulated prior to the second spawn, in the ui(), and on the FX Thread.

I think one should do something like that:

val json = model.toJson()
runAsync{
   storeUsingRest(json)
}

instead of

runAsync{
   storeUsingRest(model.toJson())
}

Sure, if your UI is constructed in a way that might change the data in

model

before the

runAsync

thread gets to it.

@jschneider sorry...i misunderstood your scenario. i thought the second Worker-Thread was only to be kicked off after the first one finished

is there anything special I should keep in mind before using runAsync?

I know it's threaded, but do I need to make sure other aspects of the design are thread-safe?

The biggest mistake i see is to add Platform.runLaters within the runAsync. It’s best to use the ui and fail because of the strict sequencing