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

[Mattias Gaertner]

On Sun, 22 Nov 2009 14:55:52 +0100
Hans-Peter Diettrich <DrDiettrich1 at aol.com> wrote:

> 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.

Yes, it is a little bit work.

 
> 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.

Let's first get some example running. Last time I tried it did not
work. Maybe you can write a text/doc how it is supposed to work.

 
> >>> 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?

Do you think this is necessary? I hope not.

 
> > 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.

ok.
I guess you identify forms by their name?


> 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?

TLazControlDocker is not visual.
What do you want to do?

 
> > 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.

The IDE should use the docking manager like any LCL app would do.

... 

Mattias