@carlw I saw your dragging example and ran it last night. It's AWESOME. Hoping I'll get to work on this project today!!! We're one dev down this week and everything is popping up on requests for clients

i think i'll get a few blog post out of it. edvin usually finds some tornadofx syntax that i missed. i also plan on moving the objects once they're on the canvas

@amanda.hinchman-dominguez grab the code from this morning. it has more highlighting features and inflight tracking of the operation (a few messages up)

I'll be sure to!

@javafxpert Looking at the code now. You're getting the hang of this 🙂 I don't like the cumbersome creation of the "Show Fill Letters" checkmenuitem, will try to improve that by adding an overload to the

checkmenuitem

builder.

@edvin uploaded a file: Before

Thanks. Please feel free to modify anything you want!

@edvin uploaded a file: After

@javafxpert I'm looking for things that could be written more idiomatic, stopped at

WordGridView

. I try to avoid saving UI elements into fields if it can be avoided, and rather communicate by javafx properties instead. Thinking about this:

private val wgCellFrags: Pane = Pane()

.

@edvin uploaded a file: Before

@edvin uploaded a file: After

This might or might not work, depending on how you proceed though.

Not satisfied yet though, something is still bothering me here 🙂

Need to understand what's going on before I can comment further.

Fragments and Views aren't meant to be instantiated manually, they should be added using

find

,

add

or

inject

. Failing to do so might mean that these components don't participate in the complete life cycle, but that's a very subtle thing, and might not be important in your use case.

Looking at WordGridModel:

@edvin uploaded a file: Let's Kotlinify this

@edvin uploaded a file: Untitled

I haven't looked at what's going on inside here, but this might be a case for

bindChildren

perhaps.

About this:

@edvin uploaded a file: Untitled

You could fire a

AddWordGridCell

event and subscribe to that perhaps. That reduces coupling at least.

This app is quite involved even if the code base is small, and I fell like I'm not able to give the best advice until I really understand it. However, if you can get things to be operational or close to, it might be easier to refactor it. I have some ideas that would reduce the complexity a lot, but right now I'm just basing it off assumptions about what's going on. Will need to study it a bit more, and I'm running out of time today 🙂

Thanks @edvin !

My pleasure 🙂 We'll make it completely idiomatic eventually 🙂

Went through the first few chapters of the guide. It did need some cleanup. I'll pick up some more tomorrow.

@amanda.hinchman-dominguez commented on @carlw’s file https://kotlinlang.slack.com/files/U25U0KPFT/F8J1NJU9J/toolbox_drag_example.kt: What's the purpose of dragging color? I'm not sure if I can apply properties to a tilesFX tile

That’s the sole item that I’m attacking throughout the operation

wow, just the color? and then you create new objects and attach them to the color?

Yeah though there could be more info. Just enough to create the target shape where it lands. By not dealing with a Node for this I don’t have to worry about transferring it among containers.