[Lazarus] IDE docking flaw?

[Hans-Peter Diettrich]

Mattias Gaertner schrieb:

>> A DockMaster has no idea of "preferred positions" etc., it only 
>> remembers the layout as configured by the user. It's up to the standard 
>> IDE procedures to position new forms to their configured places.
> 
> The IDE package that installs the dock master can provide
> default layouts.

Which are selectable how?

Currently only the user can copy/rename/link one of such layouts into 
the default layout name.

Come back when the MainBar contains a layout combo, as in Delphi or my 
MiniIDE example :-)



>>>>>> ShowForm should handle (already) docked forms by means of
>>>>>> TWinControl.ShowControl, which e.g. already handles forms in notebook
>>>>>> pages (switches to the according page). I'd add the following features
>>>>>> to ShowControl:
>>>>>>
>>>>>> - make it public
>>>>>> - add an BringToFront parameter (default True?)
>>>>>> - also make parents visible
>>>>> That would be Delphi incompatible. We have to create a new method for
>>>>> this.
>>>> What reasonable incompatibility do you see?
>>> Delphi's ShowControl does not make parents visible.
>> That's not documented, and even if it were so, it would make no sense.
> 
> Maybe the Delphians made that one up to fool us.

No, they found a need for making visible components inside tabbed controls.

As you already mentioned, Show can have many meanings WRT siblings and 
parents. I wonder if there is a legitimate expectation, that Show (or 
ShowControl, BringToFront...) would *not* make visible components with 
more than one Parent.


>>>> ShowControl already is recursive, i.e. parents become visible.
>>>> An added parameter with a default value doesn't break anything, IMO.
>>> ShowControl is a protected virtual method. Adding a default parameter
>>> changes the signature.
>> Every Delphi project must be recompiled by Lazarus, so that added 
>> default parameters require no changes to the code.
> 
> Override breaks.

Since only TWinControls can override ShowControl, such components have 
to be adopted to LCL conventions in any case, before they can be used in 
Lazarus.


> The IDE has a simple layout - only positions and size and each form is
> independent of each other. That's why the restore is very easy and
> therefore it can restore any layout in any creation order. 
> A docking layout has nested layouts and dependent forms.

It's the job of an DockMaster to save and restore every layout, that the 
*user* could construct before. I see no problems here, as the 
EasyDockMaster demonstrates[1].

Dunno what you mean by "dependent" forms. If you mean the DockSibling 
etc., used to place the Messages or CodeExplorer near the (which?) 
Editor window, this IMO is a superfluous feature. Assuming that the user 
can permanently move and resize every window, it would be sufficient to 
construct a single *static* default layout, where every form has an 
initial place and size (in the window creators). Later on the saved 
*dynamic* (user specified) layout will take precedence (in the config or 
DockMaster).

[1] The DockMaster interface and usage results in some minor problems, 
which can be discussed separately. E.g. the current workflow requires 
that all dockable forms are wrapped into floating sites, because it's 
unknown to MakeDockable whether the form is really floating, or will be 
docked afterwards by the DockMaster. This can be seen in the console 
log, where floating sites are created and destroyed during IDE startup.


>> If you want to go into details, we can collect ideas for more layout 
>> manager features, and then implement these in the IDE. When tasks remain 
>> to be done in an DockMaster, the interface should be updated and 
>> documented accordingly.
> 
> How do you want to separate the layout manager from the dockmaster?
> Just look at the two existing implementations of dockmasters. They use
> very different layouts.

Every DockMaster *is* a layout manager, which *replaces* the simple IDE 
layout Save/Restore. Only new windows, which the user never made visible 
before, are placed by the IDE. Their final (user defined) placement 
becomes part of the layout, when the IDE terminates (CloseAllWindows).

BTW the SimpleLayout should *not* remember the bounds of *docked* forms, 
instead it should retain their *undocked* bounds, for use when such a 
form is undocked later.

And the Options Windows page should *always* show the window placement 
frame, so that the user can adjust at least the extent of (actually or 
later) undocked forms, and can move misplaced forms into view, after the 
monitor count or screen resolution has changed. I've improved TScreen 
and ShowForm already, so that my ShowForm will force all forms into the 
monitor bounds. [Patch available on demand]



>>>>>> [1] As long as dockable forms are not supported by all platforms,
>>>>> Basically it works. I use the docked IDE under gtk2, qt and carbon.
>>>> Does this mean that the wrapper hack is not required any more?
>>> You mean the dock header? This is required under X. Other
>>> libraries do the same.
>> I.e. nothing has changed in the meantime. Shouldn't we start to 
>> integrate all such docking requirements into the LCL or widgetsets, so 
>> that dockable components work out-of-the-box on all platforms?
> 
> Please explain "out-of-the box" in this context.

It should be sufficient to set DragKind and DragMode, to make components 
dockable. The coder should not have to care about wrapping floating 
dockable forms into host docksites, on non-Windows platforms.

We only have to agree about according procedures (look and feel), maybe 
separately for every widgetset, and then implement that in the LCL or 
widgetsets. My EasyDocking approach (using dock headers) should work on 
every platform, but it depends on e.g. OnEndDock, which might be 
overwritten by the user. Similarly a hack is currently required in the 
DragManager, so that *moving* floating dockable forms does not result in 
flicker, caused by destruction and recreation of the floathost.


>>>>> I used it only a few times under Windows.
>>>> Using which DockMaster/Manager?
>>> Anchordocking.
>> I just tested this (Win7), and could not configure or drag-dock anything :-(
> 
> As I said: I use Windows seldom. I took a quick look and I can d&d and
> dock. I have no time at the moment to work on it.

I don't expect that *you* work on d&d, I can do that myself (for Win32 
and Linux). But I expect that nobody else breaks the formerly working 
docking by untested modifications, ignoring my according bug reports :-(


>>>> WRT Delphi compatibility: Delphi compatible docking actually is broken, 
>>>> in detail on Windows. If you think that AnchorDocking should be used 
>>>> instead, I can stop any work on other docking models.
>>> Don't get me wrong. The anchordocking has many bugs too. I only said
>>> that docking basically works in the LCL on all major widgetsets.
>> Is Win32 *not* a major widgetset???
> 
> Maybe some win32 developer can help you.

I can help myself, as mentioned above. But I cannot help when my bug 
reports and patches are not even *recognized* by the Lazarus team :-(


>>>>>> [...]This means that a DockMaster can restore the
>>>>>> complete IDE layout, when e.g. called from
>>>>>> IDEWindowCreators.RestoreSimpleLayout.
>>> That is a simple for loop. It does not create the forms in the right
>>> order.
>> What "order"?
> 
> For example parents before children.

I meant: RestoreSimpleLayout should delegate *everything* to an 
installed DockMaster, and do nothing by itself, then. Only *one* layout 
manager can be active at any time, everything else is asking for 
trouble. For that purpose I'm missing Save/Restore methods in 
TIDEDockMaster, dunno how a DockMaster currently is told to save/restore 
a layout :-(

IMO the IDE should call methods of an installed layout manager, wherever 
it currently checks for IDEDockMaster<>nil. Then the 
IDEWindowCreatorList will become the default layout manager/DockMaster, 
which can be overwritten by a user supplied DockMaster.

This could be achieved by defining a combined CreatorList/DockMaster 
base class (TIDELayoutManager), from which inherit both the 
TIDEWindowCreatorList and every DockMaster. The IDE then addresses the 
IDEDockMaster:TIDELayoutManager for all layout management tasks, while 
it still can call the specialized CreatorList methods through 
IDEWindowCreators. The common layout management methods can be 
determined by a search for "IDEDockMaster" in the IDE and IDEIntf code; 
the global procedures in IDEWindowIntf also can be moved into the layout 
manager class.

DoDi