[rkward-tracker] [ rkward-Feature Requests-1189713 ] make plugin system more modular and generic

SourceForge.net noreply at sourceforge.net
Sun Mar 26 19:12:52 UTC 2006

Feature Requests item #1189713, was opened at 2005-04-25 20:41
Message generated for change (Comment added) made by tfry
You can respond by visiting: 

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Priority: 5
Submitted By: Thomas Friedrichsmeier (tfry)
Assigned to: Nobody/Anonymous (nobody)
Summary: make plugin system more modular and generic

Initial Comment:
This is one of my long-term TODOs. I'm placing 
it in the Feature-Tracker in order to have a place, 
where I collect my thoughts about how this can 
be done. Consequently, some information in 
this tracker-item may be rather cryptic. Sorry 
about that. 
The plugin system should be reworked to be 
more modular. At the core there will be a class 
like "RKPluginComponent". 
The main ideas are: 
- Plugins should be able to simply "include" 
certain components. E.g. a plugin to calculate a 
correlation could include a component to 
generate a scatterplot for this relation. 
Improvements in the scatterplot-component 
would automatically be available in the 
correlation plugin, and there would be no need 
to duplicate code. 
Allowing a notebook or SEMMA-approach, i.e. a 
GUI-variant where you simply connect a series 
of calculations to each other 
- Easy hooks to create plugins / plugin 
components using e.g. pyQt. I.e. implementation 
of a plugin / component should be easily 
possible in different languages. 
A plugin-component will have several 
- A list of named input slots: 
For instance a component to transform a vector, 
will have an input slot for a numeric R object. 
- A list of named output slots: 
Also this component will have an output slot for 
a (transformed) numeric R object. 
- A QWidget derived GUI, allowing to set some 
options (e.g. type of transformation): 
There should be specialized input slots for each 
option settable in the GUI, so those options can 
be set from outside 
- Further specialized input slots, e.g. controlling 
the visibility / enabledness of the GUI options 
Each plugin component will have to implement 
certain calls. Most importantly the 
code-generation function currently executed 
(exlusively) in PHP: 
preprocess (), calculate (), printout (), cleanup (). 
The plugin component will have to return 
meaningful (or empty) R-code on each of these 
calls depending on its settings. 
When used as a standalone plugin, this will 
work roughly as it is now. When included in 
another plugin, the including plugin will have to 
also "include" those code-sections. 
Each component may rely on the current 
PHP-backend to accomplish code-generation or 
use its own mechanisms. 
Further ideas: 
- Special components that can be used by the 
main app, e.g. as import/export filters 
Main problems (incomplete list): 
- Find a good description of input/output slots. 
This will have to include information on types of 
input allowed / output generated, whether an 
input is mandatory, whether an output is 
available with current settings, etc. 
- Find out how e.g. pyQt-generated QWidgets 
can be integrated in ones generated by rkward. 


>Comment By: Thomas Friedrichsmeier (tfry)
Date: 2006-03-26 21:12

Logged In: YES 

The main concepts of this feature request have been 
realized. Other long term items will be tackled when the 
time comes. Closing this item for now.


You can respond by visiting: 

More information about the rkward-tracker mailing list