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.


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.


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.


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

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.


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?


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


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

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

DoDi


--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Reply via email to