Hello Tom! It is great that you are addressing these problems. It is just my usual luck that I find problems with it all the time.
Here are some comments about this: > - lots of ProjectBrowser.getInstance() calls used solely as parent for > popup dialog box. We can probably use null or figure out the main > application window using Swing calls for most (all?) of these. I wasn't aware that you were working on this. In an attempt to solve this I moved most of them into the ArgoDiagram class in the GUI subsystem? See http://argouml.tigris.org/servlets/ReadMsg?list=dev&msgNo=19828. [...] > [...] Actions managed as singletons ([...] save > project, remove from diagram).[...] > - There's a ton of code specifically for Loading/Saving projects which I > split out. Most of the Loading and Saving shouldn't be in the GUI subsystem. Instead it should be moved to some other subsystem that has knowledge of the uml model, the diagrams etc. > - jumpToDiagramShowing() is only used one place (UMLToDoItem) so I moved > it > there temporarily, but we should probably use the TargetManager or a > similar > mechanism This should probably belong to the Diagram subsystem. It is the Diagrams subsystem that knows what elements that are on each diagram. For the GUI subsystem, and possibly the ProjectBrowser, the only part of this should be "makeSureTheDiagramIsVisible(xxx)"-function. There rest of this should be located in the Diagrams subsystem. > - setToDoItem() - similar to above. The details pane should probably > listen for target changes. For the GUI subsystem, and the ProjectBrowser, the only part of this should be a "makeSureTheTabIsVisible(xxx)"-function or possibly a "displayATabThatMatches(Condition)". That it in fact is a ToDoItem tab should not be something that the GUI subsystem is bothered with. /Linus > -----Original Message----- > From: Tom Morris [mailto:[EMAIL PROTECTED] > Sent: den 2 juni 2006 20:29 > To: [email protected] > Subject: RE: [argouml-dev] The structure and purpose of the GUI subsystem. > > Linus said: > > > [the GUI class] is an attempt to break up the > > ProjectBrowser class by moving some responsibilities out of it. > > It sounds like we agree that the ProjectBrowser has turned into a tar baby. > It seems to have become the dumping ground for every piece of global state > that lacks a home of its own. > > The comment that you identified was part of a larger attempt to break the > strong coupling between the ProjectBrowser and other classes. The comment > was actually obsolete even before it was committed because I'd already > decided that it would be better for the LRU menu to listen directly for > notification of file save events (and have the file saver post those > notifications). > > I spent several hours teasing apart the ball of string that is > ProjectBrowser since Classcyle had identified it as the "best fragmenter" > for the large cycle of 758 classes. Because ProjectBrowser acts in so > many > different roles, my first task was to separate out the methods and data > for > the various roles into separate classes so that I had a cluster of > interrelated classes that I could use to trace what depended on what. > Because ProjectBrowser is basically the 2nd highest layer (after > org.argouml.application.Main) any reference to it from a lower level > component is likely to introduce large dependency cycles. > > After splitting things up and breaking a few of the dependencies I was > able > to reduce the size of the largest cycle from 758 classes to 229 classes > with > ProjectBrowser off in its own little cycle of 21 classes. > > Some of the issues that I identified with ProjectBrowser as part of this > investigation include: > > - lots of ProjectBrowser.getInstance() calls used solely as parent for > popup dialog box. We can probably use null or figure out the main > application window using Swing calls for most (all?) of these. > > - there are several references getStatusBar().showStatus which should > probably just post status events that the statusBar can listen for > > - There are a number of Actions managed as singletons (undo/redo, save > project, remove from diagram). I didn't look into which ones really need > to > be singletons, but I split them all off into a separate class just to > separate them from ProjectBrowser for investigative purposes. > > - There's a ton of code specifically for Loading/Saving projects which I > split out. > > - jumpToDiagramShowing() is only used one place (UMLToDoItem) so I moved > it > there temporarily, but we should probably use the TargetManager or a > similar > mechanism > > - setToDoItem() - similar to above. The details pane should probably > listen for target changes. > > - getTab() - only used in ToDo management - use event instead > > Most of the (private) changes so far have been just to enable the > investigation rather than production ready code, but the one small change > that I thought was non-controversial (to break the large cyclic dependency > in the GUI class introduced by > http://argouml.tigris.org/servlets/ReadMsg?list=cvs&msgNo=11447) was > immediately rejected by Linus, so I figured I should stop, summarize the > results of the investigation so far and figure out what to do next. > > I'd really like to see something done about this big ball of spaqhetti and > was willing to do the work, but now I'm unsure what the next step should > be. > Should I let someone else do this work? Should I just drop it? > > Tom > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
