In an attempt to document some IDE internals, I came across the following code in IdeWindowIntf.TIDEWindowCreatorList.ShowForm:

   if (IDEDockMasternil) and (not (csDesigning in AForm.ComponentState))
   and (FindWithName(AForm.Name)nil) then
     // show dockable if it has a creator and is not a designer form
     IDEDockMaster.ShowForm(AForm,BringToFront)
   else if Assigned(OnShowForm) then
     OnShowForm(Self,AForm,BringToFront)
   else if BringToFront then
     AForm.ShowOnTop
   else
     AForm.Visible:=true;

This bypasses OnShowForm, when a DockMaster is installed. Is this intended? What's the purpose of OnShowForm?

IMO the DockMaster should not be involved in ShowForm, this method is called too often in the IDE code. The only situations, where the DockMaster really is involved, are:
- MakeWindowDockable
- MakeWindowDockSite
- Save/RestoreLayout[1]

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
- when called with AControl=nil, show itself

The last item means: when the form has no parent,
form.Parent.ShowControl(form) is not applicable. This special situation can be handled in ShowControl, when called as form.ShowControl(nil), so that the caller doesn't have to care. I can supply an according patch, if you like.

Then TIDEWindowCreatorList.ShowForm can invoke AForm.ShowControl(nil, BringToFront) instead of figuring out what should happen.

[1] As long as dockable forms are not supported by all platforms, dockable forms have to be wrapped into a floating form, which offers means to start docking the contained control. Since such floating sites are handled by the DockMaster, all dockable forms are part of the DockMaster layout, regardless of really docked or floating. The remaining non-modal IDE forms are all docksites, which also are handled by the DockMatster. This means that a DockMaster can restore the complete IDE layout, when e.g. called from
IDEWindowCreators.RestoreSimpleLayout.

DoDi

OnShowForm existed for compatibility, but it is now obsolete. I removed it.

Showing a form can restore the old position or putting it at a default position. Your dockmaster don't need to implement the restore.

That would be Delphi incompatible. We have to create a new method for this.

Such a function is indeed useful. What could be a good name?

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.

[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. I used it only a few times under Windows.

What about the floating forms that are neither docksites nor dockable?

Mattias

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.

Delphi's ShowControl does not make parents visible.

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.

There are many definitions of 'Show'.
What about scrolling? What about multi monitor support? Other parts of the LCL have an EnsureVisible procedure that shows and scrolls to make sure the element is visible on the screen. Maybe that would be a better name?
It needs parameters for:
- bring to front: changing the z-order of the top level form
- active screen: move the top level form to the active screen. This may require changing Left,Top.

The Delphi save/restore is very limited.
It can not save/restore parts of the layout.

You mean the dock header? This is required under X. Other libraries do the same.

> I used it only a few times under Windows. Using which DockMaster/Manager?

Anchordocking.

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. That means you can use forms as child controls and you can d&d. The d&d needs improvement especially under carbon.
At the moment I have other priorities.

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

Mattias

Fine :-)

Huh?

The docked layout is entirely implemented in the DockMaster, the IDE (layout and creators) have no idea of that layout.

What reasonable incompatibility do you see?

ShowControl already is recursive, i.e. parents become visible. An added parameter with a default value doesn't break anything, IMO.

Please note that a new name will cause trouble, since ShowControl is already overridden in certain control classes. A new method would require the same overrides, and *that* is what would break compatibility.

Alternatively a BringToFront parameter could be added to Show, default=True (stupid Delphi compatible).

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

I used it only a few times under Windows.

Using which DockMaster/Manager?

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.

These don't need any special (DockMaster...) handling :-)

DoDi

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.

That's not documented, and even if it were so, it would make no sense.

Every Delphi project must be recompiled by Lazarus, so that added default parameters require no changes to the code.

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.

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

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

What "order"?

DoDi

The IDE package that installs the dock master can provide default layouts.

Maybe the Delphians made that one up to fool us.

Override breaks.

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.

Please explain "out-of-the box" in this context.

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.

Maybe some win32 developer can help you.

For example parents before children.

Mattias

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

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.

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.

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]

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

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

You gave the answer yourself:

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.

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

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

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.

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

Sorry, I still cannot find a Layout list in the MainBar :-(

My IDE model contains:

procedure TIDEForm.MakeVisible(inFront: boolean = True);
begin
   ShowControl(nil, inFront);
end;

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

How are these affected by an added default parameter?

The user specifies the position when undocking a form, whereupon the form is resized to its UndockedWidth/Height. That's Delphi docking convention - see also DockRect.

Thanks :-)

No, but it should work when Screen.Monitors returns the true monitor bounds. More complicated is exclusion of the TaskBar...

Let me know when you can spend some time for IDE docking.

Thanks for the links :-)

DoDi

In IDEWindowIntf.TSimpleWindowLayout.ReadCurrentCoordinates replace
Width and Height (ln. 831 ff.):
     Width:=Form.UndockWidth;
     Height:=Form.UndockHeight;

Dunno how you want to handle the form position. Best guess: the origin should not be changed when the form is docked (HostDockSitenil). Optionally don't change *anything* in this case.

I just came (again) across another bug, that makes the form position unusable on my multi-monitor system, with negative coordinates. IDE Options Windows GetSize doesn't return the current coordinates for a window on my secondary monitor. I'll supply my patch for proper screen bounds, including methods to fix out-of-bounds coordinates.

DoDi

Hans-Peter Diettrich wrote

> There are LCL applications. ShowControl existed since revision 5536 in > the LCL. You can find out such facts with svn blame. How are these affected by an added default parameter?

type
   TWinControl = class
   protected
     // this is the procedure that's extended by you with a default param
     procedure ShowControl(aControl: TControl; aSomeOtherParam:
TSomeType = stValue); virtual;
   end;
   // this is some 3rd party control that isn't modified, but overrides
ShowControl
   TSomeOtherControl = class(TWinControl)
   protected
     procedure ShowControl(aControl: TControl); override;
   end;

Compilation will generate the following error: There is no method in ancestor class to be overridden.

That's quite an affection, don't you think? ;)

Regards,
Sven

Your MiniIDE has default layouts, because you added them to the menu. Same can be done by an IDE package that registers a dock master.

Overrides don't compile anymore.
If you still don't understand this, please read the fine manual about virtual methods.

You are free to implement this in your dockmaster. Maybe I will implement this as an option in anchordocking.

For anchordocking the simplelayout is only important, when the user uninstalls/deactivates anchordocking. That's why simplelayout should store screen bounds of docked forms.
If I understand you correct, you want to use simplelayout in parallel with your dockmaster, right?

AFAIK Screen.Monitors changes when switching to another workspace.

And it seems the monitor bounds are not always correct from the beginning, for example when the IDE creates its first window and calls restore layout. This seems to be a general problem on all widgetsets.

ok. Probably not in the next two weeks.

Mattias

DoDi suggested fixing code imported from Delphi in the converter, but yeah, of course there _can_ be external LCL-native or shared code that uses the method. But
is it really any possibility that this is heavily used by somebody? Is it really better than add another virtual method (i.e. increase the VMT)?

Best regards,
Fl?vio

Every incompatibility makes some trouble.

Current ShowControl:
Set Visible of one control to true and switches active parent Pages.

Wanted:
A method to set Visible of control and all its parents to true, switches active parent Pages, optionally changes Z-Order, optionally calls BringToFront on top level form, optionally scrolls parent controls, optionally moves top level form into monitor bounds, optionally moves top level form to current monitor.

I think the new function is distinct enough to create a new method.

On the other hand:
ShowControl is only used by Show. The new function may be better fit for all places where Show is used. If this is the case, then ShowControl becomes obsolete and this will render the overrides useless. In that case we have to extend ShowControl and break compatibility. This needs to be checked.

About size:
If you fear about size, then the new function should not be implemented at all.

Mattias

> Sorry, I still cannot find a Layout list in the MainBar :-( Your MiniIDE has default layouts, because you added them to the menu. Same can be done by an IDE package that registers a dock master.

A menu entry is different from a ComboBox. Such a visual component can already be used by the the IDE's SimpleLayout...

For anchordocking the simplelayout is only important, when the user uninstalls/deactivates anchordocking. That's why simplelayout should store screen bounds of docked forms.

Not a good idea with notebook-docking :-(

If I understand you correct, you want to use simplelayout in parallel with your dockmaster, right?

Not really, but GetForm may introduce such a dependency. Why should a DockMaster guess where to place new forms, when the IDE already established such defaults?

May be, but how does the IDE handle such switching? [AFAIR at least Ubuntu uses system-wide screen and monitor settings]

IMO such a problem occurs only when an already running application is assigned to an different or all workspaces. What should an application do then, provided that it is notified at all?

And it seems the monitor bounds are not always correct from the beginning, for example when the IDE creates its first window and calls restore layout. This seems to be a general problem on all widgetsets.

That's why I made the ScreenBounds dynamic: GetScreenBounds determines the bounds on its first call, at least. This can be done whenever the screen manager sends a notification of changed screen resolution, taskbar position, or the like.

DoDi

Dunno how you want to make all this depending on *one* boolean parameter ;-)

ShowControl already is recursive, and a BringToFront parameter is meaningful only to the top-level Parent. This lead me to a new suggestion:

- Add a procedure (or method) that stores additional parameter(s) in a static location, and make it call ShowControl (as is).
- Update TWinControl.ShowControl to evaluate and finally reset all the options.

This allows to introduce parameters like:
- MakeVisible (applicable to all controls)
- BringToFront (applicable in top-level controls)
- MakeFullyVisible (move top level form into monitor bounds)
- whatever else you like[1] ;-)

This solution
- doesn't require any changes to the ShowControl overrides,
- doesn't change the behaviour of ShowControl when called from other places, and
- all options are handled in only one place: TWinControl.ShowControl.

[1] You can add ScrollIntoView, if you like, by overriding ShowControl in TScrollingWinControl.

When the options are passed as a set, it's easy to clear all options at
once (ShowOptions:=[];), after ShowControl reached the top level form.

When the options are added to the non-virtual TControl.Show (default=[]), no new method has to be introduced at all :-)

DoDi

Compilation will generate the following error: There is no method in ancestor class to be overridden.

The message clearly indicates what has to be done.

That's quite an affection, don't you think? ;)

;-)

DoDi

In the preparation of this patch I found a problem with the Source editor forms - they seem to have bad (default) values in UndockWidth/Height :-(

I didn't know where to send the patch, so I'll attach it to this message, for all interested readers. Above fix is made conditional, so that it can be tested easily.

The attached patch addresses the
handling of multi-monitor coordinates:
- Screen coordinates and bounds (forms.pp, screen.inc)
- allow for negative coordinates in Options Window
- and in CustomCoordinatesAreValid
and using the new methods:
- using Screen.FitToMonitor instead of agnostic checks and a minor fix:
- properly handle negative Width/Height in GetDefaultBounds

Tested on Win32 with no docking packages installed.

DoDi
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed... Name: WinPos.patch
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110608/c9533ebf/attachment.ksh>