I agree with Andreas that Settings needed to be abstracted out in a GUI independent way. This approach has already been taken for the reverse engineering code to allow pluggable reverse engineering modules to request session specific settings.
Linus said in response: > Splitting out a "settings subsystem" from the GUI subsystem > will achieve two things: 1. We can implement settings in a > GUI-agnostic way. This is very good. 2. There will be > restrictions in what settings are possible. This will > probably not be a practical problem because we can add new > means of doing settings as they are needed. The number of different types of settings is pretty small - boolean, pick one from list, file selection, etc. Even if you add more advanced things like a color picker, the list isn't going to grow very large. > I don't think this addresses the problem though, because the > subsystems with settings will still have two essential parts > (when examining the dependencies). One part depends only on > the Model subsystem(s), and the other on the "settings > subsystem". If they are not split in two, it means that also > the "settings subsystem" will have to be made available when > testing the bulk of the subsystem. Low level subsystems like Settings, I18N, etc are, by their very nature, going to have lots of things depend on them. That's not really a bad thing. What *is* bad is allowing leaky abstractions in our pluggable APIs. If we force modules to directly call Swing or GEF or other internal implementation-specific code to meet their needs, they are instantly tied to our implementation details. While refactoring the Reverse Engineering subsystem, I came to the realization that all my emphasis on maintaining API stability was ultimately silly because *every single* plugin module was broken the day that we stopped shipping NSUML because they had all been accessing it directly. Similarly, allowing modules to provide a Swing component as the mechanism for extending the Settings dialog is at entirely the wrong level of abstraction. We really need to review the entire module API to root out this kind of stuff. Tom p.s. I don't know whether PGML is considered part of the Diagram subsystem or not, but it's certainly part of GEF and it definitely doesn't have anything to do with a view. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
