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
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
