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

[Martin]

Hans-Peter Diettrich wrote:
> Martin schrieb:
>> Compiling Lazarus (SVN / Snapshot) with   -dSynDualView  allows you 
>> to open a 2nd window for any open source file. The 2nd Window can be 
>> edited, and all edits made in one window, are also done in the other 
>> window (they edit the same source).
> Very nice, have to try out immediately! :-)
>
> I get an error: uemOpenAnotherView not defined, in sourceeditor.pp?
it is in ide\lazarusidestrconsts.pas
Maybe you need to make clean all? (or tick the checkbox)

>> => All this is not likely to be fixed soon => the idea is to wait 
>> what happens to IDE docking
>
> Why wait? When we fix the details now, I know what to implement for 
> docking.
Well first, it is not wait only.
there are still bit's and pieces in SynEdit to be fixed. And 
sourceEditor/Notebook must be adapted too. So it simply is work in 
progress.

After that, it can be looked into.
> See the MasterSite example for my current suggestion:
>
> Every IDE window can become an elastic dock site, with added dock 
> panels at the left, right and/or bottom, by calling AddElasticSites(). 
> My plan is to make the editor windows such dock sites, but also the 
> main bar can be configured in the same way. This is optional eye 
> candy, can be replaced by the next option:
>
> All (other) dockable forms are wrapped into floating forms with a 
> DockManager, from which they can be docked together or into the 
> elastic sites of another window. Empty floating host sites (after 
> undocking their client) destroy themselves. Dockable forms are created 
> by TDockMaster.CreateDockable, and can be configured further by the 
> caller.
>
> Please note that the MakeSite example is not yet finished, emptied 
> notebook do not yet disappear - this will be cured in the next update.
>
> It would be nice to have any number of editor windows, creatable on 
> demand (your part).
> Persistence of the layout has to be defined. All dock sites can be 
> enumerated, and can store their coordinates, layouts and content. The 
> restauration of an layout is just unclear, with regards to the 
> recreation of the docked forms. We'll have to find a solution for 
> multi-instance forms, like editor windows, and for re-creating the 
> docked forms by their name and instance number, instead of their ID.
persistent layout, was one of the things I thought of, when I said 
"waiting".

It has to be seen how good window state/size/pos can be saved with the 
current means (because there can be any amount of edit windows)

>
> My current plan is to use the form name to specify the form type 
> (class name) to create, e.g. TMessageWindow for MessageWindow or 
> MessageWindow1 (see TDockMaster.CreateDockable). The instance number 
> can be removed from the form name for all single-instance forms, to 
> distinguish them from true multi-instance forms. This will prevent the 
> creation of new instances, when a single-instance form already has 
> been created. Every form must know whether it's single or multi 
> instance, and change its name accordingly when it's created. 
> Multi-instance forms can be connected by their instance number, e.g. 
> CodeExplorer2 will reflect the current file in SourceEditor2. The 
> layout configuration file will have to be modified, to contain the 
> form instance names instead of unique form IDs, with multiple instance 
> entries.
>
> The anchor docking and its manager is no more required, and can be 
> replaced by the TEasyDockSite and TDockMaster classes. Or the 
> TDockMaster methods can be integrated into the existing layout manager.