[Lazarus] Dockable IDE

[Hans-Peter Diettrich]

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