Anchor docking has nothing in common with drag-dock. It allows to glue forms together, in a dedicated host window. This requirement for a host window can lead to unwanted effects, when e.g. an explorer or message window is docked to an editor window - the editor window will become a child of the host window. In the Delphi docking model instead the editor window will stay a top level window, and the docked window would become a child of the editor window, When used to create a monolithic (SDI) IDE, the IDE main bar would become a child of another host window. The IDE window can not be a dock site itself, because it's impossible to dock another (single) window into an empty dock site.
The user currently is more restricted in the arrangement of docked windows than in the Delphi docking model, due to some flaws in the anchor controls. This might be improved by an extended anchor editor, as already used in the form designer. The model has more flaws and bugs, e.g. the forms tend to jump over the screen when forms are docked or undocked, and host windows cannot be merged or docked together. The dock headers have inconsistent alignment, and the anchors are not properly constructed. I don't want to go into details now, just before the next official Lazarus release.
Docking forms seems not to be a good idea, when their menus are inaccessible in docked state and further complications occur with various widgetsets. IMO we should collect all experiences with the pro's and con's of the implemented (and other) docking managers, and implement a better docking model at least for use in the IDE.
No comments:
Post a Comment