On Tue, 07 Jun 2011 02:07:05 +0200 Hans-Peter Diettrich <[email protected]> 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 better one. > >>>> 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. There are LCL applications. ShowControl existed since revision 5536 in the LCL. You can find out such facts with svn blame. >[...] > [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. 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, 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 -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
