[rkward-devel] Downloadable plugins

[Thomas Friedrichsmeier]

Hi,

I'm taking this to a new thread with a new title, so I don't have to scroll 
down quite as much in kmail...

On Friday 01 October 2010, meik michalke wrote:
> in theory, three steps are neccessary to get it to work:
>  - ask newstuff.kde.org for a repository, see "GHNS repositories" at
>     o http://newstuff.kde.org/development.php
>    i'd volunteer for the repository administration stuff.

Probably needed for easy uploads, but as mentioned, I have not really looked 
at this. I reckon, we can simply use a repository at 
http://rkward.sourceforge.net/temp/ for testing purposes? You should have 
write access, there, using
  sftp://m-eik,rkward@web.sourceforge.net/home/groups/r/rk/rkward/
 
>  - create a small rkward.knsrc file, e.g. with content like
> 
>    [KNewStuff2]
>   
> ProvidersUrl=http://newstuff.kde.org/cgi-bin/hotstuff-provider?site=RKWard
> Uncompress=archive
>    InstallPath=.rkward/plugins/
> 
>  - include KHotNewStuff2 invocation somewhere in the RKWard configuration
>    dialog. some code hints can be found at the end of
>     o http://techbase.kde.org/Development/Tutorials/K_Hot_New_Stuff2

Ok, I've added a button to this effect on the "Plugins"-page of the settings 
dialog, so you have something to start playing with. The knsrc-file is in the 
settings/-subdirectory of the sources, in case you want to change it.

> in the end this should open some "hot stuff" manager, show what's in the
> repository and allow you to download/remove available plugins. archives
> would get unpacked to $HOME/.rkward/plugins/. RKWard only has to make
> shure that new .pluginmap files are automatically added to its
> configuration.

Yes. This should be easy enough to add, but it does not happen for now.

> [btw, if it's not to big a deal to implement, i'd rather
> leave plugins packed in one archive file.]

You mean in the repository? Yes, I think that definitely makes sense. I guess 
in most cases users will want to download a set of plugins, rather than a 
single plugin.

As far as I understand the "Uncompress=always" option means that you can 
simply upload a .tar.gz, and it will be unpacked, locally.

If you mean keeping the plugins packed, locally, that may be a bit more 
difficult. I suggest unpacking them to separate subdirectories, for now.

> as soon as this works, the .pluginmap window is probably the place that
> would profit the most from some changes. what i'd like to see there would
> be meta information on all plugins, which could be stored in the
> .pluginmap file, e.g.
> 
> Active  Plugin                             Version
>   [x]   t-test                             0.5.4
>         Two sample t-test dialog
>   [ ]   ANOVA                              0.1b
>         Support for ANOVA
>   [x]   IRT                                0.5.4
>         Item response theory (Rasch model)
>   ...

I guess that makes a lot of sense in general. But are you sure it should be on 
the level of individual plugins? I think that would be a rather overwhelming 
amount of info, even today. So I'd rather operate on .pluginmaps, i.e. 
collections of plugins, here, as well. What do you think?

> i haven't found out about the details of the actually downloaded packages
> yet, but this is probably handled by the provider service anyway, so we
> wouldn't have to worry. can wait until we have something to toy around
> with, i think.

Well, let me know, if you need anything else in SVN in order to start playing 
with the concept.

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20101001/53b9c2da/attachment.sig>