Now each UIComponent can tell if it's

refreshable

or

savable

and get callbacks to

onRefresh

and

onSave

when the corresponding workbench buttons are clicked.

If you have a viewmodel in your view you can delegate the responsibility of telling the workbench about savable for example by binding the dirty state of the model to the savable state of the view:

override val saveable = mymodel.dirty

.

The save button will then only be enabled whenever the model is dirty.

I also found a nice way to delegate the savable and refreshable state to "sub-views", for example editors inside a TabPane.

The biggest challenge is making it configurable enough I think. Each docked UIComponent must be able to contribute to different parts of the workbench ui as long as they are active. Adding buttons to the button bar, custom header, custom components in the right side of the toolbar, like the search area in my CRM example etc.

We had a nice talk indeed

But the difference between a thread and coroutine needs to be more clear

It needs to be understood, us Java folks aren't used to such fine tools 🙂 I'm a bit worried about the meaning of

async

though. My first thought is that in a multi thread environment,

async

means "on a separate thread". In a single threaded environment like JavaScript, it of course can't mean that. A more clear word would be preferred IMO, but I'm not sure what that would be.

By the way, I found a very "TornadoFX" way to contribute to the Workspace. A component can simply add stuff in the

onDock

callback, and the changes it makes to the Workspace is tracked and reverted when the component is undocked. It's also possible to enter a "persistent state" where changes could not be removed on undock. That's not really useful from a docked component, but if you subclass

Workspace

you don't want the changes to made to disappear when on the next undock. This is handled automatically though.

It's eerie how well this Workspace thing is working, I keep wondering when it's going to blow up on me.

I have not looked at the workspace at all

I was looking at how you made the internalWindow and if I could adapt that for the adhocInternalWindow this morning

but the saturday is as usual filled with shopping and doing things in RL

I think the class InternalWindow needs to be adapted a bit to be able to use a rootbuilder like you do in the other classes

RL can be so distracting. My family is in Oslo, som I'm currently enjoying L, no R.

@ron I'll switch back to HEAD and look at InternalWindow in a bit 🙂

@ron Check the issue, I added a suggested implementation to it. Will you try it out and see if it fits your use case? If it works for you, maybe you'll submit a PR with it? Just add it after the other

openInternalWindow

calls in

UIComponent

.

Doing it now

I'm having some issues with switching back to head, git is not playing nice today, that's why I'm making you jump through some extra hoops 🙂

no problem

Well, git/idea/me are having some difficulties.

@ron Hmm.. combining internal window and adhocFragment is a pretty nice combo for dialogs.

it works

@User uploaded a file:

let me test it in my use case

Sweet!

why oh why does

fixedRateTimer

not have a pause?!!!!

I don't know 🙂

@User uploaded a file:

That's a big window you've got there.