[Lazarus] Autosize behaviour

Hans-Peter Diettrich DrDiettrich1 at aol.com
Tue Apr 6 09:16:58 CEST 2010


Michael Van Canneyt schrieb:

>>> 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.
>>
>> I imagine a Layout property for TWinControls, or an intermediate 
>> layer, that is initialized to the Delphi compatible manager. That 
>> property then can be assigned any other layout manager.
> 
> That is the same as what I am saying, only the arrow points in the opposite
> direction.  I want to avoid this extra TWinControl property.

I wonder how you want LCL code to use a dropped layout component. When 
no predefined property exists, every TWinControl had to be searched for 
an according component, whenever a layout method or property shall be 
accessed.

With a dedicated LayoutManager property, all anchor-docking related 
stuff could be moved from TWinControl into the AnchoredLayoutManager, 
and DockManager could be replaced (or merged with) the LayoutManager. In 
further steps the DockClient list could be removed, the Controls list 
can be used instead. Delphi compatibility can be maintained by 
delegation to the still existing elements.


>> The layout should take into account the standard TControl properties, 
>> including alignment, constraints and anchors. It also should use the 
>> layout managers of child controls, for forward/backward transfer of 
>> autosize information.
> 
> This is *exactly* what I want to avoid.
> 
> - Either one uses the 'ordinary' delphi properties, and only those.

This shall be the default, when no dedicated manager is specified for a 
TWinControl.

> - Or one uses layouters.

When a special manager is installed for a TWinControl.

> But not a mixture of both, which will be a source of implementation/usage
> problems and confusion.

What should be complicated, when the Delphi layout manager is one of 
multiple available managers? How do you want to implement different 
layout management for parts of a form?

IMO the autosize woes only result from the overcomplicated handling of 
multiple layout models at the same time (Delphi compatible and Lazarus 
anchor "docking" management).

> Keep it simple.

I *only* want to simplify everything. When every TWinControl now can 
have an DockManager, it will have an LayoutManager after the redesign. 
That manager will allow to manage the layout of every TWinControl 
independently, and the extra code for resizing DockSites can be removed.

The default manager will be the Delphi compatible one, that can continue 
to reside in TWinControl, when no other manager has been installed; or 
it can be moved into the TLayoutManager base class, or into a descendant 
of that class.

> Once this split works correctly, you can always later try to create a 
> TLayout descendent which tries to mimic Delphi behaviour, taking into 
> account all TControl/TWincontrol properties; Then remove all old code
> and insert the new layouter.
> 
> In my opinion, this approach guarantees has a bigger chance of success 
> than immediatly trying to do everything at once...

I don't understand what you want to separate - but perhaps we mean the 
same thing?

DoDi





More information about the Lazarus mailing list