On Mon, 06 Jun 2011 18:50:20 +0200 Hans-Peter Diettrich <[email protected]> wrote:
> 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. The IDE package that installs the dock master can provide default layouts. > >>>> 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. > >> 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. > >>>> 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". 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. > > >> 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? Please explain "out-of-the box" in this context. > >>> 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. > >> 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. > > 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"? For example parents before children. Mattias -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
