|
From: Sampo N. <sam...@ik...> - 2013-01-27 09:46:52
|
Hi, Good points there Richard... On Sun, Jan 27, 2013 at 6:31 AM, Richard Graham <ri...@rd...> wrote: > Configuration --- the interface should provide a standard way to > configure 'global' options for the plugins and enable/disable them. I am > thinking a simple plugins menu item which might look something like: > > Plugins > Airstart > -> [x] Enable > Elevation > -> [x] Enable > -> Configure > Find new plugins ... (opens website) > > Note that in the example of simulation extensions, this configuration is > different from the 'per simulation' configuration which should also be > available. I hadn't thought of global configuration... It may be a bit problematic for the transferability of ork files. Essentially I was thinking that all simulation extension configuration would be written to the ork files. Having global configuration options may make the files less portable. Do you have some specific examples on what would be in global configuration? I was also not planning on having any enabling/disabling functionality for plugins. Any plugin on the classpath will be loaded. Is there some need for such functionality? > I do think that we really should be able to support extensions in > android but I don't know of any good solution for not depending on > swing. It may be that we would need to have separate versions of plugins > for android. I've been thinking of two alternatives, neither of which seems totally ideal: 1. The Swing configuration is a separate plugin that is searched for separately to configure the other plugin. Essentially we'd be going through all SimulationExtensionConfigurators and asking whether you know how to configure com.example.MySimulationExtension. (If a configurator could not be found, then the plugin doesn't support GUI configuration.) 2. Some sort of indirection in the reference to the Swing portion. The JRE loads classes late, so I believe classes in use can contain code that utilizes classes that are missing (or utilize some class that utilizes a class that is missing), as long as that code is not called. Alternatively (or together) it might help to have "Object getSwingConfigurator()" which is then cast at runtime. I don't know enough of the class loading to be sure of these though. Option #1 would clearly separate the UI code, while #2 might allow a bit simpler code. After a bit of though I think #1 is the way to go, though I'm unsure how the searching should be performed. > Datatypes --- we should make sure that plugins can reserve their own > flight data types (which would then be available from > doc.getFlightDataTypes()). Making sure that there are no conflicts would > require that plugins are fully loaded before any files are loaded, which > in turn means a restart is probably required after enabling a plugin. I > guess that is ok. Do they need to reserve them? My idea has been that the data types are dynamic, and more can be created on the fly as needed. We would just need to specify properly the equals() method, i.e. what two types are considered the same and what are different. > ORK file -- it seems it should be simple enough to provide something > like a <plugin name="..."> tag in the file, the context of which would > be handed off to the appropriate plugin if available. Likewise for > simulation extension configuration. Each plugin would just need to > provide a name and version info. Exactly the "would be handed off" part I'm dubious about. How do we make a clean interface for reading/writing the configuration? One option would be to create some kind of XML parsing methods in a fashion that cannot break the XML output. Another would be to limit plugin configuration to key-value pairs which would be handled by the load/save code. I think it would be good to have some abstraction for a plugin configuration which could be fetched and set for a specific plugin, and stored/loaded in a generic way. We might even use a custom implementation of java.util.prefs.Preferences (though personally I think that class is a mess..)? -- Sampo Niskanen <=> http://www.iki.fi/sampo.niskanen/ |