[rkward-tracker] [rkward:feature-requests] #56 again: plugin improvements

[Thomas Friedrichsmeier]

- **status**: open --> closed
- **milestone**:  --> -------


---

** [feature-requests:#56] again: plugin improvements**

**Status:** closed
**Labels:** Plugins 
**Created:** Fri Nov 13, 2009 08:04 PM UTC by m.eik
**Last Updated:** Tue Jan 15, 2013 10:28 AM UTC
**Owner:** nobody

i'll re-post some of my earlier thoughts on \(what i think are\) improvements for plugin handling from the devel list, and add some new ones:

file level
==========
\- allow plugins to be a .tgz archive. rkward should be able to unpack these on the fly at startup time. pluginmaps could just have their place inside the archive and be evaluated automatically. rkward could check all .tgz files in certain configurable folders like ~./rkward/plugins and create an inventory dynamically. this would improve the installation of new plugins from the net: save archive to that folder and you're done \(would need an "update inventory" switch somewhere\).
all plugin tests should be included as well, so you could check the functionality of even third party plugins by specifying their location, if you want to.
this should still work if tarballs are extracted to the given folder, otherwise plugin development would suffer.

\- instead of the rather static pluginmap mechanism to define the menu structure, i'd like all available plugins to be presented on a configuration page, grouped into categories, with a small box to \(de\)activate them individually. \[to me positioning is not \*that\* important, but if needed should be added here as well, like moving entries up or down the hierarchy\]

xml level
=========
\- at a time it would have been of use to me if the logic section had a way of checking for the classes of selected objects, to toggle class specific options. e.g., if object in varslot is of class xy, make option a available, if it is of class yz, make option b available:
<logic>
<convert id="modelxy" mode="inherits" sources="variable.class" standard="xy" />
<convert id="modelyz" mode="inherits" sources="variable.class" standard="yz" />
<connect client="optiona.enabled" governor="modelxy" />
<connect client="optionb.enabled" governor="modelyz" />
</logic>

pluginmap level
===============
\- when working on a new plugin, i began to wish for a version number tag. several versions of one plugin should possibly be active at the same time without problems. perhaps, if rkward would ckeck for uniqueness of active plugins, it could add the version numbers to the menu entries if needed. the version numbers should also be shown in the plugin configuration. i'd suggest a new pluginmap element for this, e.g.:
<plugin name="Linear Regression" version="1.7-4" category="Regression" />

\- the more plugins become available, the more useful an optional\(?\) maintainer tag could become, too, e.g.:
<maintainer name="My Name" email="i\_am at somewhere.else" />
it could also be automatically added to each corresponding .rkh help page when it is shown.


---

Sent from sourceforge.net because you indicated interest in <https://sourceforge.net/p/rkward/feature-requests/56/>

To unsubscribe from further messages, please visit <https://sourceforge.net/auth/prefs/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/rkward-tracker/attachments/20130322/f95cbb46/attachment.html>