[Lazarus] IDE docking flaw?

[Hans-Peter Diettrich]

Mattias Gaertner schrieb:

>> This bypasses OnShowForm, when a DockMaster is installed. Is this
>> intended? What's the purpose of OnShowForm?
> 
> OnShowForm existed for compatibility, but it is now obsolete. I
> removed it.

Fine :-)


>> IMO the DockMaster should not be involved in ShowForm, this method is
>> called too often in the IDE code. The only situations, where the
>> DockMaster really is involved, are:
>> - MakeWindowDockable
>> - MakeWindowDockSite
>> - Save/RestoreLayout[1]
> 
> Showing a form can restore the old position or putting it at a
> default position. Your dockmaster don't need to implement the restore.

Huh?

The docked layout is entirely implemented in the DockMaster, the IDE 
(layout and creators) have no idea of that layout.


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

ShowControl already is recursive, i.e. parents become visible.
An added parameter with a default value doesn't break anything, IMO.


>> - when called with AControl=nil, show itself
>>
>> The last item means: when the form has no parent,
>> form.Parent.ShowControl(form) is not applicable. This special situation
>> can be handled in ShowControl, when called as form.ShowControl(nil), so
>> that the caller doesn't have to care. I can supply an according patch,
>> if you like.
> 
> Such a function is indeed useful. What could be a good name?

Please note that a new name will cause trouble, since ShowControl is 
already overridden in certain control classes. A new method would 
require the same overrides, and *that* is what would break compatibility.

Alternatively a BringToFront parameter could be added to Show, 
default=True (stupid Delphi compatible).

>> Then TIDEWindowCreatorList.ShowForm can invoke AForm.ShowControl(nil,
>> BringToFront) instead of figuring out what should happen.
> 
> Showing can require docking. So ShowForm must use the dockmaster.

Please explain.

The (Delphi compatible) persistent docking saves/restores the contents 
of docksites. Either forms already reside in a docksite, and only must 
be made visible on demand, or they have to appear according to the IDE 
Window settings when opened e.g. from the View menu.

The current DockSibling and DockAlign docking in the Creators bypasses 
an DockMaster, with many consequential problems :-(


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

> I used it only a few times under Windows.

Using which DockMaster/Manager?

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.


>> dockable forms have to be wrapped into a floating form, which offers
>> means to start docking the contained control. Since such floating sites
>> are handled by the DockMaster, all dockable forms are part of the
>> DockMaster layout, regardless of really docked or floating. The
>> remaining non-modal IDE forms are all docksites, which also are handled
>> by the DockMatster. This means that a DockMaster can restore the
>> complete IDE layout, when e.g. called from
>> IDEWindowCreators.RestoreSimpleLayout.
> 
> What about the floating forms that are neither docksites nor dockable?

These don't need any special (DockMaster...) handling :-)

DoDi