Thanks to Paul for his engagement in the improvement of docking :-)
Here are some thoughts about the organization and management of dock zones, which should be helpful in the further development. Keys: determination of the drop zone, and how to keep the dock tree balanced.
A dock zone can have several layouts (states):
- empty: the site may be entirely invisible, or may be shrinked to a minimum size.
- single client: the client covers the entire client area of the zone, the zone has no orientation.
- notebook: the notebook covers the entire client area of the zone, and can contain any number of pages.
- horizontal or vertical stack: multiple clients reside side by side in the site's client area, separated by splitters.
- custom: any other layout, like anchor docking.
Drop zones are highlighted when a dockable client is dragged over a dock zone. Two distinct areas should be treated differently: An outer area, possibly exceeding the boundaries of the dock zone, will allow to dock new clients to the sides of the zone itself. An inner area will allow to dock new clients relative to already docked clients. This separation is missing from the current LCL implementation.
Hint: assume a row of docked clients: A-B-C. Now it should be possible to insert another client to the left or right of A,B or C A - d - B - C
looks easy ;-)
But when a new client shall reside below B
A - B - C
A - d - C
or entirely below A-B-C
A - B - C
ddddddddd
things becomes tricky!
According to above classification, the dock zones should behave somewhat differently:
An empty dock zone will signal one unique drop zone (frame), entirely covering or possibly exceeding it's current extent (in case of elastic dock zones, initially being almost invisible parts of a form). The first docked client will cover the entire zone.
A dock zone containing an single client will signal orthogonal drop zones at all four borders, for it's outer zone, and a notebook area in it's inner zone. When another client is dropped, the layout of the zone will change accordingly, into horizontal, vertical or notebook layout, or into some custom (anchored) layout.
A notebook zone can have a single inner zone, for automatically appending an added client as a new page. It also can allow for docking an dropped client relative to the existing pages, when the mouse hovers over the notebook tabs - problem: the tabs reside in the outer zone of the zone, so that some disambiguation is required. Else it should be possible to move the new client into the desired position later, by dragging the tabs.
A horizontal or vertical zone will have an outer zone only at it's orthogonal sides, the management of the remaining inner zone is delegated to it's existing clients. When a client receives an "outer" drop, it should delegate the handling to it's parent, which has to keep the tree balanced. On an drop in the direction of the host zone, that client is shrinked to make room, for the client to be added to the parent(!) zone. Otherwise the layout of the affected client's zone is adjusted, and the dropped client is inserted into it, according to the signaled orientation.
That's all, so far, but it took me many hours to distill all the observed woes of the current [L]DockTree implementation into these few principles.
One more hint: re-docking an already docked client deserves further considerations:
- When exactly will the client be removed from the tree?
- What about the node becoming free/empty, possibly turning the zone layout from horz/vert into single-client?
- What if the client is dropped into its old place?
It looks like a useful implementation to me, when the dragged client control is immediately removed from its zone, but the zone itself stays unchanged in the tree, as a now empty but not resized zone. When the client finally is dropped into his old zone, nothing has to be done at all. Otherwise the client should be docked in it's new place, *before* removing his old zone from the tree. This sequence will allow to dock the client exactly as determined and indicated (by the frame) before. [If the empty zone were removed before, the tree/site layout might change, with a possible mismatch in the intended and final drop location] The removal of the now empty zone then can be handled in exactly the way, as if the client had been undocked entirely from the tree/site. When the layout changes due to that removal, the client already sits in it's new place, so that the layout can be changed in any required way.
DoDi