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.
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
