Martin schrieb:
On 17/03/2012 20:29, Mattias Gaertner wrote:
Then fix the page restore bug.
Then saving/restoring the bounds of the floating windows
(anchordocking).
On that part, I wondered why the old layout stuff was totally abandoned.
Perhaps it turned out unusable?
Even in docking, a user might want to specify fixed positions (maybe
undocked) for some windows, and restore last bounds for others.
Could the objects for the layout not have been extended?
I'd put the form bounds into a common base class, so that it can be
initialized whenever a new form (not yet part of the layout) is created,
by overriding the virtual base class method. Afterwards the layout
manager can move the (new) form to the saved/restored layout position.
It also adds additional (still to be done) work, for restoring column
width info (currently used by debug windows).
I'd use a general column layout (object), for every list control, that
eventually can be configured by the user (which columns should stay
fixed, which should be subject to dynamic resizing. Then only the
general layout information (model to use...) has to be saved and
restored, while every list will auto-adjust its columns on every form
change. A good design should not require that the user re-adjusts the
invidual column widths with every change of the containing form bounds.
Since there is an obvious relation between the widths of columns (in a
list on a window) and the window size, the column width is stored with
the layout....
See above. IMO it should be sufficient to store the column layout
*model* type, like a DockManager class type. A specific column layout
manager object can be created whenever a layout is restored. The storage
of eventual additional layout information then is up to the column
layout manager of the list, the amount and type of the additional
information should not be restricted or fixed in any way.
The stored layout information should be considered as a property
resource stream, with type specific parts streamed in/out just like with
.dfm or other resource files. The EasyDockMaster implements such
streaming, with sub-sections stored as strings and prefixed by specific
tags. XML could be used for that purpose as well, but it would introduce
another level of indirection (mapping of tags to arbitrary property
processors...).
DoDi
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
