Hello all!
My thoughts about the GUI subsystem (currently primarily residing in
org.argouml.ui) are that it is the infrastructure of the GUI and window.
If we go for Eclipse RCP, this subsystem would be more or less
completely replaced by Eclipse RCF while we keep the rest of ArgoUML
(knowledge about UML, Critics, Notation, ...) intact.
Tom did the following commit:
> @@ -93,6 +96,8 @@
> *
> * @param file The File.
> * @throws IOException if we cannot get the filename.
> + * @deprecated before 0.21.3 by tfmorris. Use
> + * ProjectBrowser.addFileSaved() directly.
> */
> public void addFileSaved(File file) throws IOException {
> ProjectBrowser.getInstance().addFileSaved(file);
The purpose of having addFileSaved() in the GUI class is to disconnect
the addFileSaved() function from the ProjectBrowser. The disconnection
was the whole purpose of introducing the GUI class.
In the Eclipse RCP case, the ProjectBrowser is probably not a JFrame (if
it exists at all) and the addFileSaved() probably registers the file in
some service somewhere in Eclipse RCP. Having other subsystems and
modules calling "ProjectBrowser.getInstance()" just to get hold of the
registration method creates a dependency to the ProjectBrowser and
consequentially to JFrame wherever that is called from.
I consider the GUI class as the "main" class of the GUI subsystem. If
there are registrations are not related to the GUI functions i.e. that
can be done without creating windows, they can be done through the GUI
class and the GUI class dispatches them to the project browser if one is
created. In a way it is an attempt to break up the ProjectBrowser class
by moving some responsibilities out of it.
If this is not a good way forward, then we should probably remove the
GUI class completely.
/Linus
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
