Restructure Builders.kt and Nodes.kt into Controls.kt, ItemControls.kt and Layouts.kt about tornadofx HOT 25 CLOSED

Single package framework sounds good. I also think the files should be restructured a bit. Controls.kt and Layouts.kt seem plausible. There could be ItemControls instead of ListControls for all that have items (ComboBox, ListView, TableView, ...). Unfortunately TreeView doesn't fit into the item concept.

BTW: I started using asyncItems(), observable() and column(). Very useful additions. 👍

from tornadofx.

I've thought about this too. Maybe we cam organize a "Nodes" package and put a separate file for each Node type in it? That might break existing code though with package paths...

from tornadofx.

Since I suspect TornadoFX will remain "lightweight" I would like to keep everything in the tornadofx package for now. We can still use separat files for either each node type or each "node group". Some files would just be too small to justify it, and Kotlin has an extra space penalty per file, so I think it's better to go with multiple classes per file.

from tornadofx.

Didn't know that, alright. I think your proposed approach makes sense then...

from tornadofx.

An alternative would be a wider group of nodes in each file, so we don't create that many files. Controls.kt could be one, Layouts.kt could be another and maybe one for list-based controls - ListControls or something, since they have lots of methods.

from tornadofx.

By the way, I've never created a framework or system with everything in one package, but for TornadoFX it just seems right, considering it's a Kotlin project (which let's you separat stuff in files, not classes) and the small size of the code base.

from tornadofx.

That is true, it is hard to break habits that are the result of conventions and constrains in Java. Okay, one package makes sense then.

from tornadofx.

Thanks @hastebrot - Hmm.. I guess we could put TreeView in ItemControls.kt anyway, after all it does operate on instances of TreeItem<T>?

from tornadofx.

Ahh, yes, I forgot. I only had my eyes on root. TreeView contains items, too. Right.

from tornadofx.

It looks like we would need to keep ´Nodes.kt` for general Node extensions, like this stuff:

fun Node.hasClass(className: String) = styleClass.contains(className)
fun Node.addClass(className: String) = styleClass.add(className)
fun Node.removeClass(className: String) = styleClass.remove(className)
fun Node.toggleClass(className: String, predicate: Boolean) = if (predicate) addClass(className) else removeClass(className)

from tornadofx.

Just spotted a potential duplication bug in toggleClass while looking at the code above, commited a fix :)

from tornadofx.

Layouts will go into Layouts.kt as well :)

from tornadofx.

I will hold off on this until #76 is resolved.

from tornadofx.

There are some questions that pop up while I restructure. For example, where does SplitPane belong? It's kind of a Layout type component, but it actually extends Control. Any suggestions?

from tornadofx.

Either all the panes should go in Layout or we need another file. Some controls work with data, other work with nodes. That should probably be the split. Do all the node-controls fit in Layout? I don't know.. What about TabPane for example?

from tornadofx.

I've commited an initial version, but I need help to verify that stuff is in the right files. Please take a look in the new files and give feedback :)

from tornadofx.

I'll take a look today. Hammering through a few things at work first.

from tornadofx.

Thank you Thomas :))

from tornadofx.

I'll take a look if I get the chance, but I've got a busy day ahead of me too.

from tornadofx.

No worries guys, have a look when you've got the time. I'll leave the ticket open until you've had a chance to look it over though.

from tornadofx.

Is there a particular strategy to how the functions are ordered within a file?

from tornadofx.

Also I noticed a few possible things:

fun Pane.textflow is in Controls.kt, but it is technically a Pane, though it is used more like a control. Are the files organized by use instead of technical difference?

The same goes for fun Pane.text, which is actually a Shape instead of a Control, and fun Pane.Imageview which is just a Node.

ToggleGroup isn't a Control (or even a Node for that matter) and isn't used like one in TornadoFX. Should it go in Controls.kt or somewhere else (FX.kt, Lib.kt)?

from tornadofx.

No, there is currently no strategy to how the functions are ordered within the file, but it would be nice with some groups of stuff ordered together. I just can't seem to find a good way to group them.

The other issues you mention are exactly the ones I encountered when I did the initial restructuring. We could focus on wether the controls structure other nodes (put them in Layouts.kt) or if they structure data (put them in Controls.kt or ItemControls.kt).

ToggleGroup is used for a particular Control, so it probably makes sense to put it next to the control it is used with.

Does this make sense to you guys? I'm honestly a little lost and open to suggestions :)

from tornadofx.

It makes good enough sense to me. I imaging there isn't a really good/intuitive way to separate everything. Especially as functionality grows.

from tornadofx.

Well, actually - as functionality grows, maybe a better way to structure this will present itself. There might become a need for a more fine grained structure. For now however, these three files are quite manageable. If anyone wants to group functions or add some comments that very welcome!

I'll close this ticket as the main objective was achieved. @ronsmits will probably have some comments with regards to issue #100 :)

from tornadofx.