[Lazarus] IDE docking flaw?

[Mattias Gaertner]

On Tue, 07 Jun 2011 02:07:05 +0200
Hans-Peter Diettrich <DrDiettrich1 at aol.com> wrote:

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

You gave the answer yourself:

>[...]as in Delphi or my MiniIDE example :-)

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

I don't know. But we don't break compatibility without need. And in
this case we can simply add a function with another name, maybe a
better one.


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

There are LCL applications. ShowControl existed since revision 5536 in
the LCL. You can find out such facts with svn blame.

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

Do you mean MakeIDEWindowDockable?
At the moment this is not called by the IDE.

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

So does the TIDEAnchorDockMaster.

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

That's just my preference: When a form is undocked it should not move. 
You can send me a patch to make this optional.

 
> 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 added an option to TIDEDockMaster.


> I've improved TScreen 
> and ShowForm already, so that my ShowForm will force all forms into the 
> monitor bounds. [Patch available on demand]

Have you tested this under Linux/gtk2?

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

I'm sorry for that. But these patches require some time to check, which
I don't have at the moment.

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

It is not called when there is a dock master installed.

> and do nothing by itself, then. Only *one* layout 
> manager can be active at any time,

Correct.

> 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 :-(

See the unit RegisterAnchorDocking as example:

  LazarusIDE.AddHandlerOnIDERestoreWindows(@IDEAnchorDockMaster.OnIDERestoreWindows);
  LazarusIDE.AddHandlerOnProjectClose(@IDEAnchorDockMaster.OnProjectClose);

See here for other events:
http://wiki.lazarus.freepascal.org/Extending_the_IDE#Project_events

 
>[...]

Mattias