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]
