[RkWard-devel] Barplot plugin

[Thomas Friedrichsmeier]

On Thursday 25 January 2007 00:55, SJR wrote:
> But this would require (as you already know from your other plugins) to
> load the package from the web which also a disadvantage. Somehow good,
> somehow bad therefore it's your decision of course.

I think, whereever we can get a "decent" level of functionality with standard 
packages, we should go with that. The list of packages providing nice 
features is *long*, and we can't reasonably expect users to install all of 
those, therefore we should avoid them for basic functionality, where 
possible. Also, add-on packages are sometimes less stable than the standard 
packages, so they may also require more maintenance work, later.

Of course we may still want to provide an additional "advanced" barplot, 
later, using the gplots package. Probably we'd want to devise some way of 
marking two different plugins as "doing essentially the same thing", or one 
as the "fancy" version of another. No good idea on that, yet.

But for the time being, I'd suggest to focus on providing the basic 
functionality first, and delay worrying about all the advanced options until 
later.

> @ Thomas
> Right now there are quite a lot plugins which do the require(something)
> trick. We have spoken about this issue in the past (I think). I suggested
> something like a "First Run Wizard" which asks the user to check if there
> are plugins which require non-locally stored packages and subsequently
> starts the (existing) procedure to install them. Actually there is no need
> for a wizard but an option in settings would also be good in therms of
> useability.

What kind of option do you have in mind? Something like "install all 
recommended packages"?
One thing we might want to consider, would be to move the "requires" 
information to the plugin XML or pluginmap level somehow. Then we could show 
lists like "package XY is required by the following plugins but is not 
installed" - Actions: install package XY, hide those plugins (might be a 
usability issue, too, though!), continue to show the plugins.
One of the problems would be plugins that don't strictly require the package 
for basic functionality, but do require it for some options. Oh well, not an 
easy issue to work around...

> I'm saying this because it can happen that people on a company 
> workplace or students on Uni-PCs have to work with RKWard but with no root
> privileges which would make installation of packages "hard".

Well there is support for a user library location, now. So at least the root 
privileges should not be too much of an issue. Of course frequently running 
into missing packages and having to install them one by one is still an 
issue.

> It could be 
> frustrating if somebody can not use this or that because a package is not
> installed. And I guess administrators could get annoyed if this happens
> frequently on many machines. Hope you know what I mean. Someting for the
> ToDo-list?

The general notion of a frist-run wizard should already be in the TODO 
somewhere. You can put additional thought (also on alternatives) at that 
place.

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20070125/f8eada12/attachment.sig>