On 18/03/2012 02:29, Hans-Peter Diettrich wrote:
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?
See other mail. it is still in use
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.
Well yes and no.
For every form layout info must be available.
I thought of creating such a base class. Bet in the end, I thought not
do do it.
From a point of providing functionality and amount of work to do it,
there is no real difference between having such an big-almighty class,
or splitting functionality in individual classes (though I prefer the 2nd)
NOTE:
- I am not saying the current structure is the right solution.
- I am saying, that the right solution can be done with layout providers
too (maybe even better)
Every window class must be registered to the IDE (or should), so when
loading information, it can be recognized and the form can be created.
However, a window class may have more than one set of defaults. Source
editor can be opened many times. Each has its own default.
So SourceEditor should be registered with a LayoutInfoProviderCreator,
that can be asked for the LayoutInfoProvider for each instance of source
editor....
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.
Every window currently registers columns with a callback, that can
provide the info.
More info can be added as needed
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
