I’m having positioning problem when a dockable is minimized and normalized, where it’s not normalizing back to its earlier position. Here’s the scenario. In the attached code, where I’ve the following areas:
West : Explorer Area (SingleCDockable)
Center: Editor area (MultipleCDockable added ot CWorkingArea)
Bottom: Output Area (SingleCDockable)
East: Split into to parts: Top for Overview area (SingleCDockable), bottom for Status (SingleCDockable)
In the above app, after I minimize both EAST side windows(dockables): Overview and Status, and when I normalize the Overview window, it’s not going back to its old position instead going to north/center! How can I make sure that it can restore back to its position? Thanks.
(Earlier I’ve included this issue as part of another thread, now separating into its own thread)
Let me first explain what is happening with a few pictures (see attachement).
The Dockables are organized in a tree. There are (invisible) nodes (orange) and the Dockables (blue). Each node either represents a horizontal or a vertical dividier.
In the moment the Overview-Dockable is minimized it stores its old location “right > top”.
After two Dockables have been minimized, the tree is much smaller.
If the Overview-Dockable is re-normalized it first looks for its old location. It can follow the “right” branch, but then a “top” branch is missing.
So it adds a “top” branch and, in this model, is on its old position…
Since the root of the tree changed, the algorithm runs in a lot of problems.
I have to give this situation a few thoughts, you are not the first discovering this kind of problems. Maybe I really need to store a lot more position-information for each Dockable. I cannot give an immediate solution but I promis to try a new (and better working) system in 1.0.8p3 or 1.0.8p4.
Is there any workaround for the time being? or should I wait until 1.0.8p3/p4 comes out (I donno the time line). In the worst case I may have to disable the minimize option!
One adhoc question: how can I find the currently selected tab (i.e. dockable, similar to JTabbedPane.getSelectedComponent()) of the CWorkingArea when there’re multiple tabs in the CWorkingArea without me explicitly tracking the current dockable (via dockable.addCDockableStateListener()), this may be required if I want to hit Menu -> Save which is expected to save the currently selected tab’s data.
This is hard coded, there is no workaround unless you want to modify the code of the framework itself.
As for the timeline: p3 is near its completion, currently I’m fixing the last bugs. Within the next 2-4 weeks.
The CWorkingArea is able to show more than just one dockable at the same time. You can ask the framwork for the currently focused Dockable regarding all known Dockables, but not for the last selected element on a workingarea. Tracking the Dockable is the best solution (and it is not that hard either ).
For the global focus: ask the DockController (CControl#intern().getController()) for the focused dockable „getFocusedDockable“. If it is a instanceof CommonDockable, ask for its CDockable:
Thank you so much Beni. I’ll be fortunate if you can address the layout issues in the P3, since this seems to be one of the critical features of the framework
In the attached program, where I’ve one CWorkingArea for creating multi-dockables in the center, and one explorer dockable (Single-dockable) on the west side. Here’s what I’ve done (I’m using 1.0.8p3, Eclipse Theme):
After opening the application, I’ve created 2 file dockables by using File -> New , twice.
On the “File 2” tab, double clicked to maximize it. Now the entire frame is occupied with “File 2” tab component.
I closed the “File 2” by using close icon on the tab.
Now everything disappears, while it’s supposed to show up the “File 1”.
Uh, a bug, but an easy one to repair. It should only happen in 1.0.8p3.
Actually the Dockable is not invisible, put something on it (e.g. a button) and you will still see that button. But its title and tab is missing.
There are seval effects responsible for this behavior:
[correct] The EclipseTheme does never assign a title to a Dockable.
[correct] Children of a StackDockStation have tabs only if there are at least 2 children.
[bug] the first Dockable is still on a StackDockStation. It should not be there, stations with only one child should be removed and replaced by their only child.
Your Dockable is associated with a CWorkingArea. Between CWorkingArea and Dockable is a StackDockStation. If fullscreen mode is activated this StackDockStation is made a child of the CenterArea.
Then you remove a Dockable, the StackDockStation is left with one child.
The SingleParentRemover sees this suspicious StackDockStation and checks whether it can be removed. But the WorkingAreaAcceptance issues a veto because the CenterStation must not be parent of your Dockable as it is already associated with a CWorkingArea. Unfortunatelly the WorkingAreaAcceptance did not consider that your Dockable is in fullscreen-mode and requires a different treatement.
I’ll upload a repaired version at the end of this week.