John schrieb:
If you think of the units as the documents, you can only relate the models to the source editor window, and it doesn't follow either model.
Count the editor windows, that implement the user interface (access) to the documents.
(Is that what TDI is ? Tabbed doc interface ?)
Right. I also found mentioned IDE-style interface in the wikipedia. The obvious need for terms for models that are neither pure SDI nor MDI leads to more confusion than clearness.
For the record, in Deplhi 4* where I have docking, I usually have all the source files in one tabbed set, form design windows separate, and all the other stuff - inspectors, watches, messages, etc, docked into another tabbed set. If the docking problems are to do with synedit, then even if we could dock all the Lazarus windows except the source editor and design forms into a tabbed set, that would be a great step forward. But I would not like to be be FORCED to have anything as a tabbed set (as in Graeme's original proposal), as you never know when you want to look at two things at the same time.
With dockable windows every user can create his own layout, from fully undocked until monolithic (everything docked to the IDE main bar).
In my docking model the SynEdits should be dockable as well, i.e. the editor notebook is under control of the DockManager; this way one can have any number of concurrently visible documents. The IDE sends keystrokes and commands to the currently active SynEdit, and opens new files in the currently active editor notebook; code explorers also should be created for every editor notebook, when the user decided to dock one to the editor window; otherwise single global instances could be used for all source code navigation tools. These aspects IMO make the big difference between single and multiple document INTERFACEs, from the technical viewpoint.
Optionally, as a replacement or extension of the MDI window menu, different layouts can be activated for distinct IDE states (edit, debug...), with possibly further distinction between form design (using OI and component palette), and "normal" source code editing. The component palette can be presented both in classic (horizontal) or new (vertical) arrangement, possibly depending on the width/height of its dock zone.
DoDi -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
