Hi, after reading the whole thread, here is what I'm going to do about this: - stick to the interface approach I recently committed - let others do the ImportSettings work
The reason for this is: I'm happy with the current import GUI as it is, changing it is not my focus for now. The Java import currently displays that swing dialog for the classpath, and I will put no effort in it to change this, portability from swing to SWT simply is not my area of interest. So, completely independent from GUI stuff, I provide an ExtendedImportInterface for allowing two types of imoporters: the standard ones which will continue to implement ImportInterface, and extenden (and for the moment experimental) ones which can do more. With 'more' I currently mean: run additional code between the import dialog and the "import munching of files" (thanks Alex for that term). This is NOT just useful for showing another swing dialog, but also for any other nongui task we now can't immagine, e.g. for initialization of creation of other than class diagrams. Regarding dependency on java.awt.Component: I believe I can remove that dependency and just display a completely independant swing frame (instead of dialog). I'll do that next. (One last remark: the ClasspathDialog is already copied to the Java module, so it's both in core and in module. So it's ready to be removed in the core as soon as we switch to the module. I say this because someone assumed that this code belongs to the core.) Thomas -------- Original-Nachricht -------- > Datum: Wed, 4 Jun 2008 04:12:37 -0400 > Von: "Tom Morris" <[EMAIL PROTECTED]> > An: [email protected] > Betreff: Re: [argouml-dev] Caution: ImportInterface extended! > On Tue, Jun 3, 2008 at 6:53 PM, Bob Tarling <[EMAIL PROTECTED]> wrote: > > > A slight side topic but why should there be a rule that a module > > should not have GUI elements. > > There isn't such a rule. The "rule" I mentioned was about source > import / reverse engineering modules. Since they have such limited > requirements on the GUI, they can be easily met by a simple > GUI-independent interface with the GUI implementation share across all > importers. > > On Mon, Jun 2, 2008 at 1:43 PM, Thomas N. <[EMAIL PROTECTED]> wrote: > > > please review what I've committed now: the changes in ImportInterface > > were reverted, and two new interfaces (ExtendedImportInterface and > > (ImportCommandInterface) were introduced. Could be usable for Python, > > too, see the Java import in the argouml-java project. > > > > I'll have a look into the new issue, Tom, and also on ImportSettings, > > but I'm short of time now. Anyway, do you (both) think the new approach > > is better? > > The new proposal is better because it avoids the interface > compatibility problems, but the new interface has a dependency on > java.awt.Component when it really has to be GUI independent to work > with both Swing/AWT and SWT. > > I just looked at what's there and realized that the Swing side of > things isn't as fully implemented as the SWT side. Why don't I take a > crack at finishing that up. ConfigPanelExtension is Java specific and > needs to be replaced with something which is built dynamically from > the information returned by ImportInterface.getImportSettings (which > isn't currently called by the Swing importer framework as was pointed > out). The classpath setting can go on this panel as well if we extend > SettingsTypes to support a List of Paths settings type. This same > control can then also be reused for things like Python or C include > path lists. > > Tom > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
