[Lazarus] IDE docking flaw?
nc-gaertnma at netcologne.de
Tue Jun 7 09:24:36 CEST 2011
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
> >>>> 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
There are LCL applications. ShowControl existed since revision 5536 in
the LCL. You can find out such facts with svn blame.
>  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,
> 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:
See here for other events:
More information about the Lazarus