I cannot understand the logic behind how it places stuff.
Can someone explain it to me?
Also how can I constrain the docks to a specific dimension? at least initially?
Also how do I make CGrid or whatever parent it has to be bound to a specific dimension so that it doesn’t resizes my window.
The CGrid lets you place Dockables like you would place Components on a Container with the null-LayoutManager. You then deploy (CContentArea or CGridArea.deploy) the CGrid, when deploying the grid a highly sophisticated algorithm converts the grid in a tree, because the Dockables are actually organized in a tree.
Start the tutorial application, you find an example with CGrid under Guide > Common > Hello World.
About the size: have a look at
- CDockable.setResizeRequest: the framework tries to give a Dockable a requested width or height
- CDockable.setResizeLocked: the framework tries to not resize the Dockable if not necessary.
About the specific dimension: call “setPreferredSize” and manually set your preferred size (e.g. CContentArea.setPreferredSize).
So if I have a SingleCDockable with a JPanle do I set the Jpanel’s setPreferredSize?
Or is that another component that is not part of Commons?
Also how do you represent a tree with x,y,width,height? it makes no sense.
I also get some weird issues where the trying to resize a dock gets stuck,even if its well withing my set minimize constraints or if I turn all constrains off.
Setting the minimum/preferred size of your JPanel which is on a SingleCDockable allows you to better resize the Dockables. If the minimum/preferred size is small, then you should be able to actually make the Dockable small.
Setting the minimum/preferred size of the CContentArea affects your JFrame directly. Otherwise the CContentArea tries to make an educated guess of what a good preferred size is - that guess is not always what you want.
I also get some weird issues where the trying to resize a dock gets stuck,even if its well withing my set minimize constraints or if I turn all constrains off.
I would need more information (perhaps even code) to give you a answer that helps you. The description of this issue really looks like you have a Dockable whose minimum/preferred size is too big.
The tree is a binary tree, each node can be „horizontal“ or „vertical“, and each node tells which of its children gets how much space (e.g. left child gets 40%, right child gets 60%). If you have the tree calculating the boundaries of each Dockable is straight forward.
The user sees only the result: the Dockables have some boundaries. The CGrid also describes the resulting boundaries. But the algorithm in CGrid finds a tree creating the desired results. If you want to know how exactly this works, have a look at „AbstractSplitDockGrid.tree()“.
Here is the example:
http://pastebin.com/Ynt2Gshb
If you play with the Canvas sliders(horizontal resize) the right slider eventually gets locked especially when left slider is way to the left making the tools and side small, actually that gets locked also since tools/side has no minimumSize.
Upon further testing it seems that the lock happens when something else is locked.
So if we have 3 panels all placed horizontally and panel 1 is constrained with setminimumSize then panel 2 gets locked too if resizing towards panel 1 even if its not constrained
If the first slider is to the left, then moving the second slider to the left would make the left most dockable smaller - but they already have their minimum size. Hence you can no longer move the slider.
It’s a simple constraint, and I agree, this is not the best solution. I’ll have to think a little bit on how to rewrite the code making it more intelligent.
So it’s design limitation?
Can you point me to the source that handles it?
I rather be constrained from resizing to the left rather then the right, maybe I can flip it around.
In the end the class “CLockedResizeLayoutManager” is responsible for deciding how far you can drag a slider. You could actually subclass it and override its “validateDivider” method - that way you could disable the restrictions. But as a result you can get really strange layouts… (Installing a custom SplitLayoutManager is done with “CControl.putProperty( SplitDockStation.LAYOUT_MANAGER, myLayoutManager )”).
Or you wait one or two weeks and I implement a solution going into the direction of “if moving one slider, automatically move the other slider as well to keep the minimum sizes valid”.
Thanks!
It will be patched in the preview build? I guess I’ll keep an eye on that.
I’ll write a message once I’ve uploaded the next build. This or next weekend.
The new version 1.1.2p1e is uploaded. Let me know whether the new behavior is satisfying, at least my tests look much better now.
Works great now,Thanks!