<@U25U0KPFT> Yeah, I guess it depends on the use c...

# tornadofx

[edvin]

@carlw Yeah, I guess it depends on the use case, but it would be nice to be able to detect issues and show them before the UI is shut down. Not quite sure what would be the best way to do that. Would be easier with an actual use case.

[Carlton Whitehead]

Save changes prompt on exit?

[edvin]

Yeah, but this is about checking for and cleaning up any long running tasks.

[carlw]

Stuff like that...i think the JVM shutdown handlers are good in a batch environment, but if you put a big handler on an FX app, there's going to be a period of time where you don't see anything and the app icon doesn't go away. Then the user heads for Force Quit or kill -9 and the whole thing is irrelevant.

[edvin]

Yeah. I think this needs to be handled at the application level, if you have long running tasks etc you might need to track those and present a UI to kill or handle them somehow.

[carlw]

Maybe like eclipse and others do it? Track progress at the per-thread level. I'm assuming the OP was talking about worker threads and not some kind of embedded peer-to-peer listener

[carlw]

tornadofx supports one level of progress right now which is fine for the singular actions supporting a control

[edvin]

We could now actually keep track of the threads in the thread pools and expose some state info about them..
hmm...

[carlw]

that's what I'm getting at. the pool maps to something displayable (and cancellable?)

[edvin]

Yes! Nice 🙂