I’m in love with the syntax of TornadoFX 😍 😂

If anyone's interested in a TornadoFX JMS client, I'm starting one here: https://github.com/bekwam/brokerme. I've used Hermes a lot, but haven't been able to get it to work with WildFly. I spent the past day verifying that my Hermes' configs work with Artemis (the WildFly implementation) and ActiveMQ, but there is an HTTP upgrade that doesn't seem to be understood with the off-the-shelf providers. So, I'm going to pull in some JARs -- as I've done in some business apps -- to talk to the message queues and topics. Mostly, I see this is a development aid to tap into the back-end and to stimulate the front-end. So far, I put a TreeView showing the basic Servers (Queues, Topics) definitions which I plan on saving to an encrypted .json file. I'm leaning toward a JWS deployment so that anyone can run javaws and I just have to load a shaded and signed JAR to my web server.

@zealous Is this

makeEditable

on a TableView column?

Yes it is.

Let me check, hang on 🙂

@zealous I see the problem, looking for a solution. It doesn't seem like we're able to identify the type correctly.

There is no case for Number ... which should be treated as a Float.

@zealous No, that's not the real issue here, and that's also wrong. Int, Double and Long also derive from Number, so that would be a disaster. This is due to a quirk with JavaFX, where SimpleFloatProperty actually implements Property<Number> instead of Property<Float>

Ok

@zealous I've committed a fix now, also pushing a new snapshot 🙂

Many thanks for the fix and your time!

@zealous My pleasure 🙂 Thanks for reporting!

@pike You can listen for changes to the

itemProperty

of the

ItemViewModel

, or any of your bound properties, depending on what changes in the API call. Then you need to manually update the item that changed, or replace all items bound to the chart, the same way you created them initially. Does that make sense?

@edvin that's what I thought. That's currently what I'm doing

@pike It would be possible to create create a function that would attach listeners, to make updates more implicit. Will be a little listener heavy though, so even if you have to write a little code for it, you'll use less memory with your current approach than something automatic 🙂

@thomasnield Hey! I'm getting ready for release, do you have time to comment on https://github.com/edvin/tornadofx/issues/495 before we push out the next version?

@carlw Do you have any time to look at https://github.com/edvin/tornadofx/issues/340 before we release as well? I'm thinking about releasing around Wednesday.

I don't know how easy/hard it is to implement, but let's discuss it and try to figure it out if it isn't clear cut for grid pane experts 🙂

I must be dumb, but if I have json ["string", "string", "string"] how do I map that to a list of strings?

@edvin for #340, what do you think of rowConstraints builders to go along with the columnConstraints builders and an additional pair of arguments to the GridPaneConstraint constructor for percentHeight + Width?

@carlw I never fully understood GridPane but that sounds like a natural thing to support 🙂 Are you able to add it?

@edvin I posted a reply on how to set up the gridpane with the existing API. If there's an improvement to be made, it's probably to push the definitions into the row() builder and possibly add a column() builder for consistency. You can keep the indexed functions (constraintsForColumns, etc), but the row{} and proposed column{} builders should have enough information to determine the target without an index.

@edvin I think it's better to keep the row and column constraints distinct instead of blending them into one definition. A shortcoming of the static methods is that you can call them on any node and the code won't fail. For example, I can call this at any time even if there isn't an AnchorPane in the entire program. AnchorPane.setLeftAnchor( this, 100.0 )

@edvin This will let you use code completion such that percentHeight would show up only in the row-oriented constraints and percentWidth would show up only in the column-oriented constraints.

@carlw Thank you, checking!

By the way, we should really implement a thread configuration strategy: https://github.com/edvin/tornadofx/issues/507

@edvin Maybe leverage the coroutines strategy for the thread pool? From the docs it looks like you launch a coroutine using a ForkJoinPool. When the threads join(), then you can close the app like in #507 https://kotlinlang.org/docs/tutorials/coroutines-basic-jvm.html

Possibly 🙂

I think I'd like to open the thread pool strategy gradually, but start by providing a way to configure the created threads.

What about

ThreadPoolConfig.daemonThreads = true

?