[Lazarus] IDE docking flaw?

[Mattias Gaertner]

On Mon, 06 Jun 2011 18:50:20 +0200
Hans-Peter Diettrich <DrDiettrich1 at aol.com> wrote:

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

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

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

 
> >>>> 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 Lazarus IDE restore has the same "limitations".

IMO you compare apples and oranges.
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.

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


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


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

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

 
> > That means you can use forms as child controls and you can d&d.
> 
> No more dragging on Windows :-(
> See my Docking fixes (#19308) - still open in trunk...
> 
> 
> >>>> [...]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.

Mattias