[rkward-devel] Importing external plugins (rk.power)
Thomas Friedrichsmeier
thomas.friedrichsmeier at ruhr-uni-bochum.de
Sun Jan 11 21:31:59 UTC 2015
Hi!
So I have just imported the rk.power plugin from our external_plugins
repo, into the "main" sources. The import did not quite work quite as I
had hope, this time around, but essentially all relevant history was
preserved in the import.
Some issues / questions:
- What do we do about the imported plugin in the external_plugins
repository? In general all changes should go to our main repo from
now on, so the plugin should be removed in external_plugins. OTOH, we
may want to defer deletion until RKWard 0.6.3 is actually released
with the plugin - or even some time longer. Meik, as the manager of
our plugin packages: What's best for your workflow:
- Delete the plugin in external_plugins, right away
- Keep the plugin in external_plugins for some time, but move it to
some subdirectory ("imported")
- Keep the plugin in external_plugins in its current path?
- The development version of RKWard supports plugins from different
sources overriding each other (the one specified to have the highest
version, _and_ compatible with the runtime version of RKWard will
"win"). Of course, this works for plugins having the same id, only.
Now, as an "official" plugin, the power plugin has the version of
RKWard (i.e. will have 0.6.3), and id "rkward::power_analysis". Would
it make sense to adjust the id on the current (external) plugin
package, so that users that have installed it will not get a
duplicate menu entry (after they have updated it)?
- Inheriting the version number from RKWard is a side-effect of
rkwarddev writing <about>-info to the .pluginmap, instead of the
plugin .xml. In general that is a good idea, too, unless - as in this
case - no pluginmap is being generated. Is there a way to control
this, already?
- I placed the plugin in analysis.pluginmap. As written earlier, if we
have a good idea on just how to split up plugins in a meaningful way,
that can still be changed. However, having separate pluginmaps for
each and every plugin (i.e. > 100 pluginmaps) would have quite
an impact on performance (and would be somewhat questionable,
usability-wise, too, IMO). So, for now, I keep following the "big"
pluginmap approach. Meik, with the new plugin management UI, and
rk.set.plugin.status(), do you still consider this an issue?
Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20150111/78e97a71/attachment.sig>
More information about the Rkward-devel
mailing list