[rkward-devel] Downloadable plugins

Thomas Friedrichsmeier thomas.friedrichsmeier at ruhr-uni-bochum.de
Sat Oct 2 18:51:02 UTC 2010


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,rkward@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
-------------- 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/20101002/9e7b897e/attachment.sig>


More information about the Rkward-devel mailing list