[Lazarus] IDE docking flaw?

[Mattias Gaertner]

On Mon, 06 Jun 2011 13:29:07 +0200
Hans-Peter Diettrich <DrDiettrich1 at aol.com> wrote:

> Mattias Gaertner schrieb:
>[...]
> >> 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.

Exactly.
For example when the user clicks on View / MyWindow the form is
created if needed and shown via ShowForm:

  if MyWindow=nil then
    MyWindow:=TMyWindow.Create(foo);
  IDEWindowCreators.ShowForm(MyWindow,true);

If the form was already created the dockmaster can make it visible.
If the form is shown the first time the dockmaster can make it dockable
and dock it at the old position or the preferred position or make it a
floating dock site etc.

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

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

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

There are many definitions of 'Show'.
What about scrolling? What about multi monitor support?
Other parts of the LCL have an EnsureVisible procedure that shows and
scrolls to make sure the element is visible on the screen.
Maybe that would be a better name?
It needs parameters for:
- bring to front: changing the z-order of the top level form
- active screen: move the top level form to the active screen. This may
  require changing Left,Top.

 
> >> 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 Delphi save/restore is very limited.
It can not save/restore parts of the layout.

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

You mean the dock header? This is required under X. Other
libraries do the same.

 
> > I used it only a few times under Windows.
> 
> Using which DockMaster/Manager?

Anchordocking.

 
> 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. That
means you can use forms as child controls and you can d&d. The
d&d needs improvement especially under carbon.
At the moment I have other priorities.

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

Mattias