[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