> My approach to this would be to use an Eclipse RCP based solution as > the standalone ArgoUML.
I agree but I'm not sure when the change should take place. How much of ArgoUML do we rewrite first and how much do we have a GUI mix of swing and SWT components in the released application when the conversion is complete. > We've already got a starting point in ArgoEclipse, so it's worth > studying that to begin with. The next steps are to: a) add missing > functionality (e.g. plugin modules) and b) continue breaking larger > plugins (e.g. entire Diagram subsystem in one plugin) into smaller > plugins (e.g. plugins per Diagram type with lower level plugins with > basic diagram functionality). Could we start off immediately with the individual diagram subsystems? argouml-core should need no references to them other than for the actions that can be registered using the existing module architecture. Any future work on module restructuring can then be done with those already as separate projects. >From this we should be able to see the common requirements for a diagram interface. Removing the common diagram subsystem would be more tricky. I imagine there are many cyclic reference between that and the rest of the ArgoUML application but with that done I'd hope we can then see what can be done to abstract out knowledge of GEF which I'm sure is also spread all over the place.. Bob. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
