Can you explain your use case in the mean time?

I constructed different canvas examples (canvas directly in scene, canvas in HBox, canvas in SplitPane, ...) to understand the layout handling for Canvas. In some cases I can use

scene.widthProperty()

to update the canvas width, in some

parent.widthProperty()

, in some I have to use

width

in

parent.layoutBoundsProperty()

, in some I need to use a custom Canvas class. So, I wanted to compare

scene.width

with

root.width

.

BTW (watched this a few hours ago and had to laugh; 7mins video): Josh Darnit plays "Exact instructions" with his children, an interesting way of getting people to have some idea what is it like do program

The difference between

Parent

and

Scene

is:

Parent

has no

width

field. The actual node we use as `Parent`/`root` is often a `Pane`/`Region` which has a

width

field, but we first have to explicitly cast

Parent

to

Region

.

@edvin no its not too much, I like it

@hastebrot Some of the sandwiches remind me of Nodes without Stages

Sidenote: Changing

canvas.width

will call

Node#impl_geomChanged()

which will eventually cause

Node#layoutBoundsProperty()

to call its listeners. So it's save to use

layoutBoundsProperty()

to clean and redraw the Canvas' graphics, I guess.

@carlw Indeed. We need to be very clear with the instructions and the dependencies between the Sandwich components are tricky.

@hastebrot The easiest way to get to the scene of a Node is probably just to wrap it in

whenDocked { }

. Then you're sure it will be connected to a scene. Either that, or override

onDock

if you want to do it outside of the builder hierarchy.

whenDocked

can be used inside any builder.

@hastebrot I was thinking of starting FX developers who add code (bread) to -at-FXML initialize methods without the actual screen dimensions (peanut butter)

Hm.. Maybe the drawers should support being docked in the bottom or top as well? Like the compile output, debugger and console windows in IDEA...

Then the progress thing might be a normal drawer, which can be expanded to show more info on running tasks etc.

We might need support for placement, spacers etc.

And icon-only drawers perhaps.

I think a progress drawer would be useful, but i was writing more about visual feedback being given when something long-running is taking place. This isn't always when looking at an open progress drawer

or maybe you could pack a dynamic behavior into your tabs? make an extended widget button that displays something interesting in addition to supporting open/close?

Yes, that's exactly what I'm thinking about.

so, progress is just one more drawer but with a fancier rendering and all drawer tabs can be moved around the frame

The Drawers might need a

cell

Exactly!

I'll save the dnd stuff in this first iteration though.

what's the mechanism that puts a drawer tab on the left or the right?

@evin Playing with the DrawerTest, how hard would it be for a

close()

call on an item in a workspace to automatically go back in the view stack and then remove itself from the view stack?

It has a property called

dockingSide

, and I lay it out based on that.

For the actual placement in the Workspace, I put it in the

left

or

right

borderpane slot, and now possibly the lower.

Or would it even be worth it?

right, open up the bottom for now, then worry about dragging the tabs around

@Ruckus That would be pretty nice. Shouldn't be hard to do.

@carlw Yes, and think about how to support cell rendering. Right now the buttons are ToggleButtons, it might be enough to utilize the

graphic

node they already inherit from

Labeled

.

exactly...and the progress cell might include an actual progressbar and label\