Dockable panes

[jwezorek]

Are there any plans to add some facility for creating the kind of application window in which there is a central user content area surrounded by a system of docked panes where panes may be resized and/or detached?

This is a pretty typical application design e.g. Photoshop, Blender, Visual Studio, etc. all have this high level design. In Qt it is implemented as QDockWidget and QMainWindow.

Also sometimes a distinction is made between "toolbars" and docking panes. Microsoft GUI frameworks (e.g. WinForms) only support docking toolbars as 1st class citizens; docking panes can be implemented but their implementation will be mostly custom. It would be nice to not make the distinction, I think. Docking toolbars could just be a kind of fixed size and re-orientable docking panes.

[Xeverous]

I would really like this feature too because it gives users a lot of freedom to reorganize UI structure, this is especially true for complex editors that may spawn multiple panels with very arbitrary sizes depending on user input - in such case it is really hard to supply a good default layout.

Docking/moving would require some support from tiling classes/factories but I don't see unsolveable problems on the way - these mechanisms already support adding and removing elements at runtime. I guess @djowel might already have an idea how to implement it without too much complication of internal code.

Undocking to a separate window would be problematic, as elements don't generally hold any state beyond critically necessary which means logic that happens beyond the scope of the element (such as removing itself from parent container and spawning a new window) will not be trivial to implement and may complicate public API. Given library's core goals, the core event loop implementation is not finished (it works but does not meet the goal of being able to integrate elements into custom event loop) which means that the implementation may change significantly in the future - I would not really go for implementing window-docking until this is complete. These are just my thoughts of someone who has contributed many PRs and issues.

[Radagan]

Same here! This is exactly what I was considering for my current project.

[djowel]

I think this is good to have and captures the 'modern' GUI feel. The tricky part here is that Elements is supposed to be independent of the Window and the Application (e.g. for plugins that do not have direct control over those), but I think it can be solved by a dockable-pane class and a dockable-window. The dockable-pane version (maybe the base class), only works within a view. The dockable-window version can communicate with elements::window to spawn/unspawn a new window when needed.

[redtide]

The tricky part here is that Elements is supposed to be independent of the Window and the Application

Just wondering:

• isn't too restrictive a docking system with floating panels forced to move inside a view or is this tiling and tiling is considered docking? (I have no experience with tiling window managers)
• is there a reason why when using native windows for docking it is necessary a parent window handle or can we just use a view in both cases, when used in a plugin or a standalone application? I mean, isn't the view the client area required for docks?