hi, am Freitag 01 Oktober 2010 (20:29) schrieb Thomas Friedrichsmeier: > On Friday 01 October 2010, meik michalke wrote: > > - ask newstuff.kde.org for a repository > > Probably needed for easy uploads
and probably reliable creation of XML files, download statistics (if anyone needs this) etc. but of course you're right, for testing rounds it's not mandatory. somewhere i read that a GHNS repository could be served directly from SVN, but the links to further documentation were dead. > 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/ hm, i tried all i could think of (even renewed my password), but i couldn't get there. for that matter i fell back to reaktanz.de -- with some minor adjustments it works already :-) > 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. haha, first thing i did was a screenshot :-D > The knsrc-file is in the settings/-subdirectory of the sources, in case you > want to change it. 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? since a normal user cannot drop files there, the installation doesn't really work (no error is reported, though). mine looks like this right now: [KNewStuff2] ProvidersUrl=http://R.reaktanz.de/GHNS/reaktanz-provider.xml Uncompress=always InstallPath=.rkward/plugins/ in addition to reaktanz-provider.xml i also created o http://R.reaktanz.de/GHNS/rkward.xml which holds the actual plugin catalog and is in turn referenced in the provider XML file. if you read it, it's not too hard to guess what goes where. usually there ought to be three catalogs with a different sorting order (latest, most downloads and best rating), but for the time being it all links to that one file. if you would like to test this with the preconfigured sourceforge temp folder, someone with write access should copy these two files there: o http://R.reaktanz.de/GHNS/rkward-provider.xml o http://R.reaktanz.de/GHNS/rkward.xml you'd either have to rename "rkward-provider.xml" to "provider.xml" or change that in the .knsrc file (which should be changed to use "InstallPath=" anyway). long story short: i was able to successfully install the klausuR plugin this way. uninstall didn't work, though, but i don't think that's a problem on our side (shown as "not installed", but all files were still there, see below). > As far as I understand the "Uncompress=always" option means that you can > simply upload a .tar.gz, and it will be unpacked, locally. yes, "Uncompress=archive" has the same effect, but applies only if an archive was downloaded. makes no difference for us, i guess, because we won't host wallpapers or stuff like that. > If you mean keeping the plugins packed, locally, that may be a bit more > difficult. I suggest unpacking them to separate subdirectories, for now. well, yes, that was actually my idea ;-) like open office stores it's documents in one zipped archive. it has practical advantages: - uninstall works. GHNS can unpack a downloaded archive, but it doesn't seem to keep track of which files go where and hence cannot reverse the process. if a plugin remains in one file, GHNS will actually remove it if uninstall is chosen. - installation is safer. if the archive already extists, you must confirm to overwrite it. existing unpacked plugin files, on the other hand, will just be overwritten without a cough. - upgrading is more reliable. unpacking a newer version only overwrites the existing files, but it wouldn't remove files that are no longer part of the new plugin, which could cause problems. but for the time beeing, we can do without all that, and it wouldn't even change a thing for potential plugin contributors if it changed later. > > 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? sure, it's just a sketch. my main concern is that the mere display of a .pluginmap path and file name, as is sufficient now, wouldn't be enough. i too thought of operating on .pluginmaps still, just changing their appearance (adding some useful meta information to get what's what). it doesn't have to be for each and every menu entry, but on the other hand, a toggle for the global all.pluginmap is not really useful either ;-) basically my idea is to somehow add to the static all.pluginmap some flexible config file that can be altered by a user, e.g. by toggling parts on/off like above. perhaps something like a blacklist: if none is present, default is that all plugins are active. if a plugin gets switched off, it's top level ID from the .pluginmap get's added to a $HOME/.rkward/plugin.blacklist kind of file and is omitted? > > 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. it seems the XML files are all that's needed. the actual plugins can be hosted anywhere in any format we like, their URL is just referenced in the provider files. viele grüße :: m.eik -- dipl. psych. meik michalke institut f"ur experimentelle psychologie abt. f"ur diagnostik und differentielle psychologie heinrich-heine-universit"at 40225 d"usseldorf
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
