Effectful Docking

In the last days I've been playing with several visual effects in docking. One such effect are initially invisible docking sites, which will occupy space only while controls are docked into them. Here the enter/leave events can be used to temporarily show the hidden site. Very nice to see, but it revealed more problems in the LCL layout manager.

Another attempt were docking outside the dock site itself, like side-by-side docking. This is already used by the LCL persistent docking approach, only without visual feedback. Here again the visual effects revealed problems in the LCL, with the resizing of the dock sites, and also with the dragmanager. It looks as if the layout manager has problems with shrinking forms or controls. The drag-dock implementation does not really allow for target locations outside the reported docking site extent (GetSiteInfo).

After all these experiments it seems to be the best and simplest solution, for a dockable IDE, when all parts are made dockable, including the initially fixed parts of e.g. the editor window(s). Such a dedicated window can have a menu, toolbar and statusbar, but even the edit notebook should initially be docked into the form, so that no special code is required for distinct docking sites within the form, and the user has really full control over the layout.

Another idea are rearrangeable elements, which are not intended to be moved outside their original site. This were the first useful application for a last-minute cancelled docking operation, that otherwise would make the dragged control floating, when the user attempts to move it out of its dedicated container.

Inspired by the hierarchical OS-X browser I came across more docking variations. With dockable lists a hierarchy can have a dynamic layout, not restricted to only vertical or horizontal orientation, and even with a mix of both elements. Then it might also make sense to minimize docked elements, implementing something like the drop-down list of a combobox, with the option to also show the list permanently, not only during a list selection.

It also turned out that the dockheader placement is not always related to the dock zone orientation. The first case became obvious with the tabbed notebook docking, where the dockheaders effectively reside in their own (toolbar) area, on top of the client area, by default. In a more grid-like layout the dockheaders could become column headers, where normally the headers would be part of the docked controls' separators. Finally something like the new Delphi component palette could be implemented, with a vertical list of dockheaders, where every such sub-list can be expanded on demand. The irregular case, when no child zone is expanded at all, can either be prevented in code (like an AllowAllUp=False property of a toolbar), or by adding a dummy zone at the end of the list, that is expanded by default, when all other zones are minimized.

A docking manager also could allow for switching the site layout, from e.g. tabbed into a list, so that both the old and new component palette could be implemented without the need for two distinct (notebook and list) container controls.