[rkward-devel] Downloadable plugins

[meik michalke]

hi :-)

Am Samstag, 2. Oktober 2010, 20:51:02 schrieb Thomas Friedrichsmeier:
> well that did not keep you busy for long ;-)

wasn't that much of a challenge yet ;-)

> > good advice, i had to change the provider URL for testing, and the target
> > definition, because "TargetDir=rkward-plugins" points to the system wide
> > directory, doesn't it?
> 
> I assumed it would install to ~/.kde/somewhere, but I had not tested.

hm, i'll check that. anyway, as a user i'd assume the RKWard config directory 
would be the obvious place to store its plugins, too.

> > [KNewStuff2]
> 
> Go ahead commit that to SVN, I'd say. Certainly makes it easier for the
> rest of us to take a look.

it's already in SVN and the current daily built packages. check it out :-)

> > well, yes, that was actually my idea ;-) like open office stores it's
> > documents in one zipped archive. it has practical advantages:
>
> Hm, while KDE has kioslaves for that, these usually work asynchronously,
> which would probably make the code a good deal more complex at some
> places, and may cause some performance problems.

isn't this a step that could be done once at startup of RKWard? like scan all 
archives in some default directory, cache the result and use it until plugins 
are added/removed or RKWard quits?

> Perhaps we can use a hybrid solution of some sort: Let GHNS install zipped
> archives, but unpack them after the download, from our code.

hm, ok, that should work. then the unpacked plugins would be something like a 
cache ;-)

> BTW, is there a possibilty to store meta information such as a required
> minimum version of RKWard?

i don't think so, but i haven't found a proper documentation on the XML files 
yet. anyway, i think this could be handled by RKWard more flexibly, see below.

> Why don't you make a start and add such meta-info to the .pluginmaps? I.e.
> make a list of useful info, decide on how to decloare this info in the
> .pluginmap-files, and update the documentation, accordingly?

ok, before this is added to any documentation, i'd like you to have a look at 
this first proposal and speak your mind. the thing is, when this is added to a 
.pluginmap, RKWard as of now skips the whole plugin:

<!DOCTYPE rkpluginmap>
<about version="1.0">
  <plugin
      name="Square the circle"
      shortinfo="Squares the circle using Heisenberg compensation."
      version="0.1-3"
      releasedate="2010-10-04"
      url="http://eternalwondermaths.example.org/23/stc.html"
      license="GPL"
      category="Geometry"
  />
  <author
      name="E.A Dölle"
      email="doelle at eternalwondermaths.example.org"
      url="http://eternalwondermaths.example.org"
  />
  <dependencies
      rkward=">= 0.5.3"
      R=">= 2.10"
      package="heisenberg (>= 0.11-2), DreamsOfPi (>= 0.2)"
      repository="http://rforge.r-project.org"
      rkplugin=""
  />
</about>
<document base_prefix="" namespace="rkward">
...

some comments:
- i versioned the <about> section, so that if at a later point we see the need 
to change anything, i.e. add one tag or rename another, that wouldn't 
automatically break old plugins.
- in a first draft i had everything in one <aboutplugin /> tag, but found that 
somehow too confusing
- values inside an argument should be separated by commas, if needed
- some of this information should automatically be included in the help 
  page(s) to the plugin, like version and author/maintainer, so that bugs and
  requests don't spam the devel list. even if no help page was prepared on its
  own, RKWard could generate one with basic support information from this
  section.
- <plugin />:
 - releasedate might be redundant, but maybe nice to have, so i'd vote for 
   "optional" here
 - the category should be freely definable, but might be used to later group 
   plugins in the configuration dialog etc.
- <dependencies />:
 - these should all be optional, but might be needed for certain plugins
 - the repository argument is probably the most delicate one... but since some 
   packages do reside in places that are probably not defined by the user yet,
   there should be some way to at least communicate that. i'd propose a 
   warning message at plugin installation time like "this plugin depends on
   package Foo, which is not installed. if you proceed, the following
   repositorie(s) will be added to your repository configuration. the required
   package(s) will be installed the first time they are needed."
 - rkplugin is intended for cases where one plugin uses parts of another 
   plugin

> Yes, but we can simply toss all.pluginmap, once we have a decent interface,
> and use the individual maps, instead.

guess you're right ;-)


viele grüße :: m.eik

-- 
  dipl. psych. meik michalke
  abt. f"ur diagnostik und differentielle psychologie
  institut f"ur experimentelle psychologie
  heinrich-heine-universit"at d"usseldorf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20101004/b391bd4c/attachment.sig>