[RkWard-devel] Barplot plugin

[Thomas Friedrichsmeier]

On Thursday 25 January 2007 08:44, I. Soumpasis wrote:
> This is a conversation that I would like to do sometime, it seems that now
> is the appropriate time. It is a kind of question of uniformity and how
> close to R should be rkward. Let me explain. We probably should decide
> (probably as plugin policy) if we will use package like lattice and/or
> gplots that give different colors from the traditional R plot engine. For
> example if use barplot2 gives color barplots thus barplot gives gray plots.
> Lattice package gives more different colors. I hope you understand what I
> mean.

Well, as written in the reply to Stefan's mail, I think the policy should be 
something like: "Avoid add-on packages unless there is a striking reason to 
require them". This is a somewhat diffuse and soft rule, as whether something 
consitutes a "striking reason" is not easily answered sometimes.
I think the goal should be to make as much functionality as possible work 
using only standard packages. We cannot ever hope to cover the full range of 
functionality provided by R and all addon packages. It's just too much, and R 
is just too flexible. So when designing a plugin, some important questions 
should be:

1) What functionality is likely to be useful to a large number of users?
2) Can that functionality be had from standard packages, or do we need 
add-ons?
3) How should the generated code be written to make sure that it can easily be 
reused - and potentially modified to more specific needs - by users with 
little to moderate knowledge of R?

The idea behind 3) is that plugins should not simply "do something", but try 
to do it in a way so users can use the generated code as examples and 
building blocks for automating and fine-tuning tasks (that's also why I'm so 
pedantic about style and formatting in the generated code).

> One more thing is how far to get barplot. For example for barplot you can
> get stacked bars, juxtaposed,  or vertically or horizontically bars. Should
> we give options for these and if yes in a different tabs? Or is it enough
> this I have done? Neither on stacked nor on vertically bars we can add
> values. I took a look to SPSS, Minitab and Rcmdr, and they use only
> vertically bars. What do you think?

I think it really depends on what you think is a common need. We should try to 
cover common needs as much as possible, but - as detailed above - we cannot 
ever hope to cover everything that R allows for.
My personal feeling in this particular case is that the current level of 
functionality is good enough for now. If later e.g. horizontal bars become a 
popular request, or somebody just wants to implement them, it can be added 
then. On the other hand, if you personally feel horizontal bars would be nice 
enough to have to justify the work, then just go for it.

> I could suggest for this  the rkward package for R to have as dependencies
> the packages needed. I remember Rcmdr if you install with dep=T then
> installs needed packages, If not however when you open it it says that for
> Rcmdr to work properly you should install some packages. I do not know if
> that helps in some way.

I'm afraid, this solution won't work out for technical reasons. The rkward 
package is typically installed in a different way than Rcmdr. Rcmdr you 
simply download from within R, while the rkward package is installed with the 
application itself, from outside of R.
Also, I think it's a good think to not be too strict about dependencies. E.g. 
there may be a plugin requiring package XYZ, but many users simply will not 
ever have a need for that plugin, and should not be forced into installing 
package XYZ. Some other users may not be interested in plugins at all, but 
simply use RKWard as an IDE. They, too, should not be forced to install a lot 
of package that they just don't need (and with all the associated problems, 
such as a third party package may temporarily not work with a new release of 
R, be uninstallable for a period of time, etc. The more we introduce hard 
requirements, the higher the risk of running into such problems).

Suggested first step: Let's compile a list of packages that we think are 
particularily important to RKWard, i.e. used in many basic plugins. Then we 
can in fact implement some variant of a First-Run Wizard to suggest to the 
user to install whichever of those packages are missing in one go.

I'll start out the list with R2HTML. Which other packages are (almost) 
essential?

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/af209571/attachment.sig>