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="doe...@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
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ Virtualization is moving to the mainstream and overtaking non-virtualized environment for deploying applications. Does it make network security easier or more difficult to achieve? Read this whitepaper to separate the two and get a better understanding. http://p.sf.net/sfu/hp-phase2-d2d
_______________________________________________ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
