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?
Currently only the user can copy/rename/link one of such layouts into
the default layout name.
Come back when the MainBar contains a layout combo, as in Delphi or my
MiniIDE example :-)
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.
No, they found a need for making visible components inside tabbed controls.
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.
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.
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.
It's the job of an DockMaster to save and restore every layout, that the
*user* could construct before. I see no problems here, as the
EasyDockMaster demonstrates[1].
Dunno what you mean by "dependent" forms. If you mean the DockSibling
etc., used to place the Messages or CodeExplorer near the (which?)
Editor window, this IMO is a superfluous feature. Assuming that the user
can permanently move and resize every window, it would be sufficient to
construct a single *static* default layout, where every form has an
initial place and size (in the window creators). Later on the saved
*dynamic* (user specified) layout will take precedence (in the config or
DockMaster).
[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.
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).
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.
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've improved TScreen
and ShowForm already, so that my ShowForm will force all forms into the
monitor bounds. [Patch available on demand]
[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.
It should be sufficient to set DragKind and DragMode, to make components
dockable. The coder should not have to care about wrapping floating
dockable forms into host docksites, on non-Windows platforms.
We only have to agree about according procedures (look and feel), maybe
separately for every widgetset, and then implement that in the LCL or
widgetsets. My EasyDocking approach (using dock headers) should work on
every platform, but it depends on e.g. OnEndDock, which might be
overwritten by the user. Similarly a hack is currently required in the
DragManager, so that *moving* floating dockable forms does not result in
flicker, caused by destruction and recreation of the floathost.
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.
I don't expect that *you* work on d&d, I can do that myself (for Win32
and Linux). But I expect that nobody else breaks the formerly working
docking by untested modifications, ignoring my according bug reports :-(
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.
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 :-(
[...]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, 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 :-(
IMO the IDE should call methods of an installed layout manager, wherever
it currently checks for IDEDockMaster<>nil. Then the
IDEWindowCreatorList will become the default layout manager/DockMaster,
which can be overwritten by a user supplied DockMaster.
This could be achieved by defining a combined CreatorList/DockMaster
base class (TIDELayoutManager), from which inherit both the
TIDEWindowCreatorList and every DockMaster. The IDE then addresses the
IDEDockMaster:TIDELayoutManager for all layout management tasks, while
it still can call the specialized CreatorList methods through
IDEWindowCreators. The common layout management methods can be
determined by a search for "IDEDockMaster" in the IDE and IDEIntf code;
the global procedures in IDEWindowIntf also can be moved into the layout
manager class.
DoDi
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
