[Lazarus] Layout [was: Lazarus Goal]

[Hans-Peter Diettrich]

Graeme Geldenhuys schrieb:

>> probably know Java has solved this problem nicely with layout 
>> managers.  If layout managers were implemented in Lazarus the IDE
> 
> 
> I fully agree, layout managers (or even only one layout manager) would
> solve this problem. LCL has Anchors (a lot more advanced compared to say
> Delphi 7's anchors), which goes some way to solve the problem, but it is
> still a hit and miss case - as Lazarus proves. Constantly Lazarus
> dialogs are broken, due to components overlapping, text being clipped
> etc... This gives the application a very unpolished look. A layout
> manager normally solves layout problems, preferred sizes, including
> handling size changes due to language selections etc..
> 
> I am working on a solution though, but unfortunately the work in
> progress is very slow at the moment due to day job (work) related
> deadlines. I started implementing the Java MiG Layout Manager - first to
> be used with fpGUI Toolkit. But the original design of MiG Layout allows
> for other GUI toolkits to plug in very easily with minimal code needed.
> I will try and duplicate that design, so that MiG Layout Manager can
> work with fpGUI and LCL.

In my development of an docking manager I came across the idea to 
separate the docking related methods from the layout of the dock site. 
Using that separation, a GUI designer could work like a DockManager, 
with added features for rearranging the layout, while the layout manager 
part would handle the layout at runtime. Every container component in a 
layout (currently all TWinControls, later every DockZone) could have its 
own layout manager, not restricted to one single (tree) layout for an 
entire site (form, panel...). This approach would allow to implement the 
traditional (Java...) layout managers without additional cost, and most 
probably also would fit the MiG layout.

The "dock" zones (here better: layout zones) could be used for an 
additional structure of a GUI, invisible at runtime, establishing points 
of reference for the control placement (similar to anchor docking). The 
anchor docking approach looks to me too unsystematic, with too many 
degrees of freedom that make it hard to implement and use; otherwise 
it's just another layout management system, that can be used in any 
layout zone.


The technical implementation could look like this:

The TWinControl.DockManager is used as a layout manager (when assigned), 
in the following referred to as LayoutManager. When no special manager 
is installed, a reference to an default manager object could be 
returned, so that all docking and layout related functionality can be 
moved out of TControl and TWinControl, into the default manager class.

The layout and docking control methods of TControl and TWinControl 
simply defer to the new LayoutManager. This allows to replace the Delphi 
docking model by any other one, that is more appropriate to non-Windows 
platforms and widgetsets, without breaking Delphi compatibility.

TWinControl.DockSite only activates the docking related methods of the 
LayoutManager.

TWinControl.UseDockManager is quite obsolete then. It could indicate 
that a special LayoutManager has been installed, otherwise the default 
manager (doing almost nothing) is used.

The anchor docking related fields are removed from TWinControl and 
become part of the LayoutManager. Persistence and property editing must 
be handled somehow, just like for every other docking/layout manager.

Splitters can be removed as standalone components, and can become part 
of the layout management of every layout zone (kind of combination of a 
TPanel with an TSplitter, where the splitter position and visibility is 
determined from a single property of the combined component).

The form designers cooperate with the installed layout managers, using 
their virtual methods. The managers can use the inherited designtime 
methods, implemented in their base class, in csDesigning state. The 
designers can use the existing docking capabilities of the managers, no 
need to reinvent the wheel.

DoDi