[Kst] [Bug 109459] New: custom widgets for plugins !!

[Nicolas Brisset]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=109459         
           Summary: custom widgets for plugins !!
           Product: kst
           Version: unspecified
          Platform: unspecified
        OS/Version: Solaris
            Status: UNCONFIRMED
          Severity: wishlist
          Priority: NOR
         Component: general
        AssignedTo: kst kde org
        ReportedBy: nicolas.brisset eurocopter com


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 !