This discussion was started in issue 5597, but does not belong there. Michiel said: ------------- Anyhow, the current active diagram is currently managed by the ProjectImpl, in the ActiveDiagram member. Its getter and setter are deprecated, but they should not be.
Currently, every project has exactly one active diagram. An alternative architecture would be that every ProjectBrowser has one active diagram... that would even be better, in the future case that every Project may have multiple ProjectBrowsers. Tom said: --------- ..., TabDiagram (not ProjectBrowser) should concern itself with windows containing diagrams, including which windows are open, which one is active, etc. Projects should know what diagrams they contain and have no concept of what windows/diagrams are "active" (which is entirely a GUI concept). Editing commands need to derive the correct diagram/project from the window that is being operated on, but the resulting action/command should be entirely self-describing and completely independent of any concept of active project/diagram/window. It should be possible to have multiple open projects, multiple open diagrams and even multiple open windows for a given diagram. With the correct architecture, this is trivial. With the current design, it's impossible. Michiel: -------- Agreed, I did not think that far through yet. One small remark: If the TabDiagram maintains the notion of the active diagram, then the Presentation Tab depends on it, since it only works on Figs on the current diagram. I do not know how that would fit in. Anyhow, it is a bit early to deprecate functions that have no replacement (architecture) yet. Kind regards, Michiel ------------------------------------------------------ http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=1033267 To unsubscribe from this discussion, e-mail: [[email protected]].
