[Lazarus] Autosize behaviour

[Michael Van Canneyt]

On Mon, 5 Apr 2010, Hans-Peter Diettrich wrote:

> Michael Van Canneyt schrieb:
>
>> In Delphi, you can make dock zones along the edges of your
>> form by dropping 4 panels and aligning them along the edges of the form. If 
>> autosize=true, then they have size 0 when the app is run (not when 
>> designed), but you can dock controls on them, since there is a "fuzzy" zone 
>> of 10 pixels.
>
> Such DockSites should work without AutoSize, because their extent is 
> determined by the DockManager - which is not involved in autosizing. The free 
> extent of an elastic docksite should be user-adjustable, by means of an 
> splitter. They worked until now, at least with the Win32 and gtk2 widgetsets.
>
> The influence rectangle of a docksite is the control's rectangle, extended by 
> 10 pixels in every direction. It it used only in the determination of the 
> target site, not in the layout.

I know. That is why setting

>
>> No code is needed, and you can then dock toolbars etc. along the edges of 
>> the form.
>
> Code is needed to extend and shrink the sites - also in Delphi.

Not at all. I have a counter-example on my disk here.

I didn't test docking 2 controls on it, but when docking only 1 control, 
you don't need any code whatsoever in Delphi.


> The docked 
> size of the controls is not normally useful to determine the extent of a 
> docksite, instead the DockManager controls the layout of the site, by 
> adjusting all docked controls to the given extent of the site.

And this is not so in delphi when the panel has autosize=true.

>> Unless someone has a better idea for dock zones around the edge of a form
>> without having to write code...
>
> I already asked for an (user selectable) layout manager some time ago. Such a 
> manager would replace or include docking managers, that essentially control 
> the *layout* of a docksite, while docking itself is only a minor addition. 
> Then AutoSize should be handled by the applicable layout manager, and anchor 
> docking will become just another layout manager. A stable algorithm and 
> protocol (API) has to be established, that allows all layout managers to work 
> together.

I have been thinking about layout managers. I think that this should be an add-on
to the currently existing layouting (to preserve delphi compatibility): 
I imagine a component that one drops on a form. 
One sets the 'target' control (control whose children should be managed) and some 
properties.

Depending on the layout one wants, a different component must be dropped:

TLayout
+-  TAbsoluteLayout
+-  THBoxLayout
+-  TVBoxLayout
+-  TTableLayout
+-  TBorderLayout
   ...
Each descendent has different properties. Changing the layout just means
dropping another component; something that can be done run-time.

Something like this exists in ExtJS, and it works very well.

The only thing I am unsure about is whether TControl should be made TLayout-aware.
As far as I understand, a layouter only needs to be able to handle rectangles,
within some restrictions (some callbacks to get min/max rectangles). 
It need not know anything about TControl or it's properties, and as such could
be implemented totally independent of the LCL.

I discussed this idea once with Mattias Gaertner, but he seems to disagree
on the TControl-unawareness, if I recall correctly.

Maybe the planned Lazarus day in the netherlands would be a good place to
discuss this and settle things  once and for all :-)

Michael.