Version: 1.2.0_devel (using KDE 3.4.0, compiled sources) Compiler: gcc version 3.4.3 OS: SunOS (sun4u) release 5.8 I had already sent a couple of mails to the list with questions around special needs for plugin interfaces, but I think a bug report makes things easier to trace... and the issue is important. This may require some design effort (George, are you listening ?) but it will be well worth it (I think). Basically, the problem is that plugins should be able to provide a custom interface widget. Vectors and scalars will continue to be passed in and out like now, but for other types of values it would allow the use of checkboxes, radiobuttons, combos, etc... and make plugins much more generic. Look at the default plugin list today : a lot of entries are actually either filters, fits, of interpolations. If we could provide a QWidget * to the dialog that allows to select e.g. the interpolation type (and options ?) from a combo box, we could have just one entry for interpolation in the plugin list ! The same applies to other types of plugins. This issue seems to me to be closely related with the datasource config widgets. The same principles could probably apply: provide a read() method to get defaults from a KConfig, a load() and a save() method to read/write specific settings in a .kst file, and get the appropriate pointer in the plugin implementation code to be able to retrieve all needed informations. I have a new filter plugin in the plans with a colleague, using a discretization method to compute results more efficiently than over the frequency domain (as currently). This plugin could also be used to easily implement Butterworth, Chebyshev, etc low/high/band pass filters, but having one entry in the plugin list for each combination would result in far too many sorts !
I am going to discuss plugins with the biggest users soon. Hopefully that means early September. We've been trying to use a plugin system that was in use elsewhere and the limitations of it, along with the difficult interface, make it very inconvenient. Instead of hacking in our idea of "widgets", I think we need to reconsider my original suggestion of using a C++ (perhaps KPart) based plugin system. Requirements from Planck presently prevent my from just implementing this, however.
I'll be watching the (hopefully at least partially public) discussion... Note that I do not really care (or rather, I will gladly leave it up to you to decide) how it is implemented as long as we can make more generic plugins and reduce the number of plugins needed at the end :-)
Will be implemented iff a new plugin system is created.