Graeme Geldenhuys schrieb:
probably know Java has solved this problem nicely with layout
managers. If layout managers were implemented in Lazarus the IDE
I fully agree, layout managers (or even only one layout manager) would
solve this problem. LCL has Anchors (a lot more advanced compared to say
Delphi 7's anchors), which goes some way to solve the problem, but it is
still a hit and miss case - as Lazarus proves. Constantly Lazarus
dialogs are broken, due to components overlapping, text being clipped
etc... This gives the application a very unpolished look. A layout
manager normally solves layout problems, preferred sizes, including
handling size changes due to language selections etc..
I am working on a solution though, but unfortunately the work in
progress is very slow at the moment due to day job (work) related
deadlines. I started implementing the Java MiG Layout Manager - first to
be used with fpGUI Toolkit. But the original design of MiG Layout allows
for other GUI toolkits to plug in very easily with minimal code needed.
I will try and duplicate that design, so that MiG Layout Manager can
work with fpGUI and LCL.
In my development of an docking manager I came across the idea to
separate the docking related methods from the layout of the dock site.
Using that separation, a GUI designer could work like a DockManager,
with added features for rearranging the layout, while the layout manager
part would handle the layout at runtime. Every container component in a
layout (currently all TWinControls, later every DockZone) could have its
own layout manager, not restricted to one single (tree) layout for an
entire site (form, panel...). This approach would allow to implement the
traditional (Java...) layout managers without additional cost, and most
probably also would fit the MiG layout.
The "dock" zones (here better: layout zones) could be used for an
additional structure of a GUI, invisible at runtime, establishing points
of reference for the control placement (similar to anchor docking). The
anchor docking approach looks to me too unsystematic, with too many
degrees of freedom that make it hard to implement and use; otherwise
it's just another layout management system, that can be used in any
layout zone.
The technical implementation could look like this:
The TWinControl.DockManager is used as a layout manager (when assigned),
in the following referred to as LayoutManager. When no special manager
is installed, a reference to an default manager object could be
returned, so that all docking and layout related functionality can be
moved out of TControl and TWinControl, into the default manager class.
The layout and docking control methods of TControl and TWinControl
simply defer to the new LayoutManager. This allows to replace the Delphi
docking model by any other one, that is more appropriate to non-Windows
platforms and widgetsets, without breaking Delphi compatibility.
TWinControl.DockSite only activates the docking related methods of the
LayoutManager.
TWinControl.UseDockManager is quite obsolete then. It could indicate
that a special LayoutManager has been installed, otherwise the default
manager (doing almost nothing) is used.
The anchor docking related fields are removed from TWinControl and
become part of the LayoutManager. Persistence and property editing must
be handled somehow, just like for every other docking/layout manager.
Splitters can be removed as standalone components, and can become part
of the layout management of every layout zone (kind of combination of a
TPanel with an TSplitter, where the splitter position and visibility is
determined from a single property of the combined component).
The form designers cooperate with the installed layout managers, using
their virtual methods. The managers can use the inherited designtime
methods, implemented in their base class, in csDesigning state. The
designers can use the existing docking capabilities of the managers, no
need to reinvent the wheel.
DoDi
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
