@kevinherron That's not a bad way to go. I just wish the TornadoFX guide was complete. The goal is that you shouldn't need to know JavaFX to start working with TornadoFX, but we're not completely there yet.

well pay attention to the questions I ask and take notes

ha

Will do 🙂

lazyPopulate isn't in the guide at the treeview section

@kastork I would have expected

headingContainer.removeFromParent()

to actually remove it. will investigate why that's not happening.

@kastork It seems to be because headingContainer isn't attached to it's parent during

init

. Will check if I can change that.

@kastork No way to really change that. You can either use

hide

, or override

onDock

and call

removeFromParent

on it there.

@edvin ok, it seems reasonable to do it in

onDock

, would you do it (or not do it) on each view you switch to?

@kastork If it should always be hidden I would prefer to deal with it in the Workspace subclass. Let me see if there is something I can do to make it easier customizable. You just don't want it, right?

I'm playing with my design...

for panels that just do one thing, it seem redundant

but there might be other kinds of panels where it makes sense to have some (changing) value there

but I guess in that case I can just add my own control

Yeah, I'll add some kind of boolean expression to control whether a title is shown in there or not I think.

@kastork I added

Workspace.showHeadingLabelProperty controls whether the heading is shown in the Workspace toolbar or not

@kastork So calling

showHeadingLabel = false

inside

init

should do the trick.

in the

init{}

of the Workspace subclass?

so,

lazyPopulate

doesn't react to an

ObservableList

being returned the same way

populate

does 😕

@kastork Yes, you can do it wherever you want, since it's an observable property, bound to the label removed state.

@kevinherron Let me have a look.

@kevinherron Confirmed. We should be able to fix that though. Could you create an issue? I won't be able to look at it tonight it seems.

sure, i'll make one. thanks

@edvin fwiw, lazyPopulate does do subsequent requests for child nodes in a

task {}

, but it fetches the roots immediate children on the UI thread

i actually modified

lazyPopulate

to fetch immediate children of root in a

task {}

as well and achieved what I'm after

@kevinherron OK, great 🙂 I have some plans for future improvements now at least.

i'm a little confused about how to end up with a useful controller. by useful, I mean a controller that, e.g. has an HttpClient instance for making calls. If my controller is going to be `inject()`'d everywhere, how does it get properly instantiated in the first place with the HttpClient?

@kevinherron I'm just learning the framework also, but if I understand it correctly, when you want to instantiate something in a component and keep it around, you would either do it in the

init{}

block, or else in a

val

declaration. I'm not completely sure about the lifecycle but I believe singletons like Controllers are instantiated the first time they are requested for injection.

yeah, but how do i give my controller the things it needs to be instantiated?

all the examples assume the controller has a no-args constructor