If we can access the children list of a Node, the stackpane can be added. However, the LabelSkin in this example might not do anything useful with that stackpane.

is it a runtime check or something through the code analyzer that would prevent stackpane being added as a child of label?

But that shines a light on another issue to consider actually. The builders are available on

EventTarget

for a reason. Some times there isn't a common super class we can add the extensions to, so the alternative would be to add them to several classes.

This means we would have to do some serious refactoring if we wanted to change this.

Possible of course, but painful for sure.

I played a little with dsl marker support today, and ran into some troubling issues. Enabling dsl marker in our builders would remove access even to field members, which will for sure result in ugly code and workarounds. I'm starting to believe that dsl markers are not the way to go in it's current form, unless they introduce an option where you can allow access to field members at the very least.

@edvin is there a way to bring some of these ide checks in with an inspection? Something that shows up when you analyze the code?

@carlw I'm not sure what you mean, Carl.

Is there some way to add an inspection marking or metadata to the Type Safe Builders to check for invalid children?

I'm thinking about the JetBrains NotNull annotation

Nothing that would be of any help to us I'm afraid.

@User uploaded a file: Button Not Showing Up and commented: @edvin I'm describing a feature for a newcomer who runs this code but wonders where the button is.

There are Kotlin inspections, but I don't have a Kotlin Source option to use in building a custom one.

@User uploaded a file: and commented: Missing Kotlin Source

@carlw We can actually detect this situation and fail it at runtime. Maybe we should? We can do that for all known UI nodes that cannot contain children.

Maybe ask the community if it is better to fail fast or get up and running

I think your dsl whitelist is a good idea. Could you make it just a tornadofx thing for now? Something like dsl-config.xml to describe a set of classes?

The custom inspections I suggested might not be powerful enough. How about a plugin that knows about the dsl config

@carlw I'd have to really dig into the plugin architecture to make this happen. I'll wait until Daniil has investigated further, maybe he can come up with something. Having the compiler enforce this would best for sure.

Agreed. It also would leave out eclipse users who may be the primary target, getting their first look at tornadofx outside of IntelliJ

That's a very good point.

@ron - your blog post made the Kotlin Weekly Newsletter 🎉

?

kotlin weekly what?

Hey guys quick question I am using FontAwesome in my project as icon labels. To make it work I use this https://bitbucket.org/Jerady/fontawesomefx project or the project controlfx. I was wondering how you guys are integrating font icons in tornadofx?

The workspace uses it

https://github.com/edvin/tornadofx/blob/master/src/main/java/tornadofx/Workspace.kt there it is done using css

see the

addClass("icon", "back")

for example at line 162

oh wait those are not fontawesomeFX

but svg