> 1. The details pane appears as a set of tabs in one tab. > > > I spent some time looking into this during GSoC but as you pointed out the > DetailsPane contains a lot of logic which made seperating each of these out > into their own Eclipse views a little difficult. > > I think DetailsPane has too much responsibility in ArgoUML. Personally >> I think the panels added to DetailsPane should be responsible for >> listening to TargetManager and handling their own enablement etc >> rather than DetailsPane sharing some responsibility for this. >> >> If we can move some of the logic out of DetailsPane could the panels >> be added as individual panes in argoeclipse. > > > Yes this would be easy. >
This would make things fit much more naturally into the Eclipse scheme since each tab would be a separate view and could be managed independently. Keeping them all docked together at the bottom of the screen would emulate the current behavior, but you could also choose to arrange them any other way you wanted. 2. There is only one diagram tab. > Would this result in the same problem as the details pane with >> argoeclipse only having one diagram tab with multiple tabs within >> that. >> > > I depends on how this change is implemented. > > If I resolve issue 610 can argoeclipse show separate diagram tabs at >> the same level as other open files in the project? > > > Do you mean having an editor for each diagram? I suppose with some changes > to ArgoEclipse's editor this would be possible. We'd have to create an > IEditorInput which worked with Diagrams instead of Projects like they do > now. > > I think something similar to the MultiPartEditor used in Eclipse PDE's > Manifest editor might be more appropriate ( > http://www.eclipse.org/articles/Article-Eclipse-and-Maven2/images/pde-update-classpath.png). > > I think an (Eclipse) editor per diagram is a more logical mapping than using a MultiPartEditor. MultiPartEditors are usually used when there a fixed number of separate pages, not an arbitrary number of views. There's an additional issue lurking just under the surface here in that ArgoUML only allows a single project to be open at a time, so if you attempt to open a second project, you get a very un-Eclipse-like error telling you to close your first project before opening a second. A related thing that we need to think about is how ArgoUML projects and Eclipse projects relate. For the RCP version of ArgoEclipse, we could get away with using the current file system based view with the user managing the directories for code generation and reverse engineering, but in an Eclipse IDE environment where Argo is just one of many plugins, developers are probably going to want tighter integration between their UML model and their Java/C++/whatever code. In this case, we probably just want an Argo "nature" that can be added to a project along with the Java nature or whatever other natures it has. I haven't thought through how this would all work though. Tom
