Hi, well that did not keep you busy for long ;-)
On Saturday 02 October 2010, meik michalke wrote: > am Freitag 01 Oktober 2010 (20:29) schrieb Thomas Friedrichsmeier: > > 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 :-) While using your reaktanz-server isn't a problem, for the time being, being able to write to the project web space might well come in handy one day. Perhaps you can take a look at http://sourceforge.net/apps/trac/sourceforge/wiki/SFTP to see if there is any helpful info, and open a support request at sourceforge, otherwise. Perhaps it's the '-' in your account name? > 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. > 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/ Go ahead commit that to SVN, I'd say. Certainly makes it easier for the rest of us to take a look. > > 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: 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. Perhaps we can use a hybrid solution of some sort: Let GHNS install zipped archives, but unpack them after the download, from our code. BTW, is there a possibilty to store meta information such as a required minimum version of RKWard? > 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). Ok, it will be a while until I get around to code something. 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? > 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. Yes, but we can simply toss all.pluginmap, once we have a decent interface, and use the individual maps, instead. > 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? Perhaps. But I guess we'll start with working on .pluginmaps, and then progress incrementally from there, if we feel we should offer more control. 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
