[Lazarus] Autosize behaviour

[Michael Van Canneyt]

On Tue, 6 Apr 2010, Hans-Peter Diettrich wrote:

> 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.

I would use a mechanism similar to the datalink. As soon as you tell the 
layout manager to manage a certain control, a hook is installed in the
control.

>
> 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 reason I don't want to introduce the layoutmanager property is that it
simply does not make sense for all TWinControls. a TEdit does not need a
layoutmanager, only the parent of the TEdit needs one.

>>> 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?

Simply drop 2 layouters, and point them to the right parts of the 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?

I think we mean the same thing, it's just some details that are different... :-)

Michael.