[Lazarus] Dockable IDE

[Martin]

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