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,rkw...@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
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
