I agree. When the "business" is mainly moving pixels, that business belongs in the View itself.

Maybe a port of this simple program would highlight how a shape-driven project would look. http://bekwam.blogspot.com/2015/12/sprite-programming-with-javafx-and_13.html

How did the tearable windows end up?

Interesting 🙂

@carlw I'm about to merge the first iteration, with a very minimal feature set. My plain is for the call interface to be final, but how the window is implemented will probably change over time. For that reason I think most of the implementation details will be final/private for now.

Basically, you can open the window by specifying a fragment, modality and optionally what node it should cover. If no node is given, it will cover the root node of the current view.

You can either specify a UIComponent KClass and an optional scope, or send in an actual UIComponent instance that should be the content of the floating window.

I'm not quite sure about the best name for this feature. For now it's called Floating Window.

I've seen tearable (bad choice b/c of how it sounds in English), dockable, and detachable. Floating Window sounds fine to me

@edvin Have you thought about game programming in TornadoFX? You probably were looking for a good API after having to compute a lot of offsets and keep track of drag events when you built the Floating Windows.

@carlw I'll go with Floating Window for now then 🙂 Thanks for the feedback!

@carlw I looked at a gaming API for JavaFX a while back, and I'd like to investigate it more closely to see if we could integrate better with TornadoFX. I understood that it was under quite heavy development so I decided to wait for a bit. Would like to take a closer look at it after we're done with the guide.

The drag events gave me some head ache, but mostly because I didn't know the correct behavior would be. I'll show you in a bit. I think people might have different ideas about what would be the best behavior for resizing and dragging as well, so I might end up with supporting multiple behaviors/modes.

I haven't come up with a good DRY solution myself. Been repeating this across projects.

@carlw What's your most common use case for this? I.e, why don't you open a separate window? (I have some use cases of my own, just want to hear your 2c)

@edvin I'm thinking about the overall drag and drop of Nodes or other objects. Detachable Tab -> its own Stage in one case, moving a Node within a Stage in another

@edvin for the game suggestion, if you don't find a good java project to wrap up, maybe start with a Sprite.kt and go from there?

@carlw I see. Maybe we can make the drag thing reusable. And I like your idea about Sprite.kt!

@edvin Maybe a SpriteContainer class and the two work in tandem (maybe with the Scene too) to move items around

@edvin LMK what you think. My interest is in the graphical side of business applications (ex dragging a selected set of Agile tasks from DO to DONE) rather than games for leisure

@carlw Sounds like the right focus for TornadoFX indeed. Do you want to start working on it? If not, I'd have to wait until the guide is finished.

@edvin I'll port over my SortMe app and see if I get any inspiration. If it's good I'll put it in Kitchen Sink and we can see how to generalize it.

That sounds like a very good start.

if you look at the code from Carl (the sprite sort game) looks quite elegantly written

Hi @carl, What do you mean?

@elect I was wondering if you were able to write Java code against the kits and were looking to Kotlin-ify or TornadoFX-ify the Java code.

I wrote them in java

initially, and since I discovered Kotlin a couple of months ago, I am porting all of them to Kotlin

@elect You've taken the C/C++ libraries and called them from Java using JNI?

no, pure java port