[Lazarus] New experimantal beta feature - View same source in multiple Windows

Hans-Peter Diettrich DrDiettrich1 at aol.com
Sun Nov 22 14:55:52 CET 2009


Mattias Gaertner schrieb:

>>> The unit ldockctrl is only about anchordocking. You don't need to
>>> use or alter it for your docking manager.
>> LDockCtrl describes the interface that is nailed into the IDE units and 
>> methods. 
> 
> Which were always in IFDEF, so no one will cry if this is changed or
> broken.

The unit is in the uses of many units, the types are reflected in class 
fields etc.

I've tried to exclude the LDockCtrl stuff from the IDE, by an 
conditional exclude of everything inide the LDockCtrl unit, and it 
requires a lot of additional IFDEFs. I can provide an according patch, 
if you don't want to complete that yourself.


>>> Have you solved the layout restore in your docking manager?
>> I can't, as long as I don't know how the IDE windows are created and 
>> managed (owners...). There seems to exist a dedicated OwningComponent in 
>> the IDE, that holds references to some (most? all?) IDE windows. The IDE 
>> also has to iterate over all windows when the configuration is stored, 
>> it's not yet clear to me how this works (TIDEWindowLayoutList?).
> 
> This depends on your docking manager.

I can design the docking manager according to any needs. Do you want me 
to reinvent the entire IDE form layout classes and procedures?


> For example the anchor docking manager works like this:
> There is one central TLazDockingManager object and every window that
> should be dockable gets a TLazControlDocker with a unique name.

The TLazControlDocker is evitable, since all docking information is 
already stored in the DockManagers. The forms do not need to know 
whether they are dockable, and where they are actually docked. Their 
DragMode and DragKind can be changed from outside, as is done in 
TLazControlDocker.SetControl.

Since I've introduced an dock grabber (the pin icon), this image control 
could replace the TLazControlDocker. I only didn't succeed in making it 
a new visual component, perhaps you can help me with this task?


> The IDE only needs to call LoadFromConfig/SaveToConfig (and of
> course the default form positions).

That information has to be provided in a way that the IDE currently 
uses. That's why I intended to stay with the current config files and 
procedures, and only add to it the docking specific information.

> But: the anchor docking manager is
> not finished.

I noticed that - restoring the docked IDE layout makes the IDE unusable :-(


> The OwningComponent exists only to destroy components (and
> FreeNotifications). Windows that are destroyed by code don't need this.

In "normal" applications all such forms are owned by the Application 
object. I found a notice in the IDE code, that this results in some 
slowdown, but didn't understand the rationale.



> Maybe you can write a text and/or wiki how to use your docking manager?

The usage is simple, see the MakeSite example. It's sufficient to create 
an TDockMaster instance, and to call DockMaster.CreateDockable for every 
dockable form. When Load/SaveConfig is added, it will only store the 
docking information. When the positions of other forms shall be handled 
as well, another registration method (e.g. CreateNonDockable) can be 
added (to be specified).

When special docking to e.g. an editor form is desired, AddElasticSites 
does this job. Otherwise it would be sufficient to have fully featured 
TSynEdit descendants, that can be docked into any notebook (see the 
SiteTest example). The synchronization of the editor instances can be 
implemented independently from any docking issues.

If you want to retain the current SourceEditor forms, the docking 
manager will not handle the pages in their notebooks - you have to 
restore the open file pages (tabs) yourself. With dockable SynEdit 
controls it would be possible to add a FileName property to the stored 
docking layout information, so that the docking manager can also restore 
the editor pages. Then the SynEdit components can register themselves in 
an file editor pool, that handles e.g. multiple editors for the same 
file - just as you are currently implementing. I'd suggest to implement 
something like a VirtualSynEdit component, that works with a detached 
instance of the editable text.

DoDi





More information about the Lazarus mailing list