Hello,
I have noticed inconsistent behavior with the Dock command, when we have a floating ToolWindowContainer with ToolsWindow in it. If I right click on the title bar (ToolWindowContainerTitleBarContextMenu) and select Dock, the entire ToolWindowContainer with all it's ToolWindows are docked in the main DockSite, at the previous location it was when the ToolWindowContainer was in a Docked state. This is a behavior that we want in our software, to restore the whole group back in the DockSite with a simple click command, so clients with trackpad doesn't have to drag the floating window back on the DockSite. It's a less tedious process with a clickable command in ContextMenu or the Options menu.
However, if we have floating ToolWindowContainer with ToolsWindow in it and click on the options menu (ToolWindowContainerTitleBarOptionsMenu) and select Dock, only the current ToolWindow in the ToolWindowContainer is moved to the DockSite and becomes docked. The other ToolWindow in the floating container are still floating. If we have 5 ToolWindows in the floating container, we will need to do that process 5 times before all those windows are in the docked ToolWindowContainer.
I would have expected that the Dock command from either the context menu or the options menu have the same effect when ToolWindowContainer is floating. Because it is the case when the container is docked and you choose Float from the context or options menu (it will make only the current tool window floating, not the whole container).
This can be reproduced easily in your example demo Simple IDE.
Is it a bug from your side? Otherwise, is there a way to specify that, when we have a ToolWindowContainer in floating mode, that the Dock command in the Options menu have the same behavior than in the context menu, and sends the whole ToolWindowContainer in docked state?
I hope the explaination was clear enough and let me know if you have any additional questions.
Thank you,
Alex
