[RkWard-devel] distribution plugin

[Thomas Friedrichsmeier]

> I guess you know what my idea was to give each plug-in a single folder.
> It was only a matter of readability. Moreover, new programmer would
> likely get more into it because they would immediately see what is
> important and it's more easy to reject non-working parts. That was the
> whole behind "my structure".

Ok, yes. To a certain degreee it's a matter of taste. I'll admit that probably 
the main reason why I wanted to get rid of the deep directory structures, is 
that those are cumbersome to handle in version control and makefiles. Two 
somewhat better reasons are:
1) Avoid having dozens of files all called "code.php" and "description.xml", 
which can get pretty confusing
2) Sometimes plugins in a single "module" (such as distributions) may want to 
share some files. Currently there are not much opportunities for such 
sharing, but you could for example have something like a "common.php", which 
gets included from the other .php-files and has a re-usable function to 
format the output table (this might acutally be a good idea to do). This sort 
of thing is much easier to get right in a flat directory tree.

> I'll do so as soon as possible. Regarding to SF username should I send
> you a private mail?

Whichever way you like. I don't need a password or anything, just the 
username. Then I can add this username to the list of developers and give you 
access to CVS.

> Of course I'll have a look myself but any comment or "bug report" from
> you is highly appreciated. (Also from the others). 

Ok, I'll send them as I find them. Here's a few:
1) "upper tail" in the distributions. I have not looked at all distribution 
functions, but in general the correct syntax is "lower.tail=FALSE" instead of 
"upper.tail=TRUE". Hence you should write:

              <radio id="tail" label="Choose type of probability" >
                <option value="lower.tail=TRUE" label="lower tail" />
                <option value="lower.tail=FALSE" label="upper tail" />
              </radio>

BTW, since "lower.tail=TRUE" is the default, you could also write this 
instead:

              <radio id="tail" label="Choose type of probability" >
                <option value="" label="lower tail" />
                <option value=", lower.tail=FALSE" label="upper tail" />
              </radio>

and change the php slightly to:

rk.temp = (qbinom (p = <? getRK ("p"); ?>, size = <? getRK ("size"); ?>, prob 
= <? getRK ("prob"); ?><? getRK ("tail"); ?>))

That's slightly less readable in the plugin itself, but the generated code 
would just omit the "lower.tail=..."-parameter in the default case.

2) typos "Minumum" instead of "Minimum"

3) in the plots there are some widgets not yet used in the PHP, and also, in 
box-plot there is a reference to "xlabel" that does not exist in the GUI.

4) Not really a bug, but is there any special reason, why you use

rk.temp.date <- date ()
...
cat (..., rk.temp.date,  ...)
...
rm (rk.temp.date)

instead of just

cat (..., date (), ...)

? 

Some items for me to fix:
1) placement of label for radios should be fixed
2) somehow limit the initial width of the varselector-widgets

> What do you think 
> about the interface (maybe I should have a look at the gnome "human
> interface guidelines" :) )?

Well, I'll take a look at fixing the above two layout-problems (there's no way 
to do this from the plugin side).
About interface guidelines I'm certainly not a good authority. I wouldn't know 
what to do better.

> Interface is a good point. I was wondering if we should write something
> like a wrapper for charting? As we all know is charting (accept with
> error bars) a strength of R. Anyway, there are to many arguments for
> charts but these are repeated frequently and this might be a starting
> point. I came up with this idea when I was trying to write the
> distribution plug-ins. A wrapper would just be the normal triplet
> plugins.pluginmap, code and description but without any functionality.

I'm not sure, if that's you're thinking about, but the key idea behind the 
current rework of the internal code of the plugin-system (aka the mess I'm 
fighting for the next release), is to make it possible to reuse more 
elements. For instance, you'd have a "plugin" that does not do anything more 
than providing a GUI for the common options of "plot ()", and of course 
generates an option string from the GUI-settings. This "plugin" would not be 
of much use on it's own, but could simply be embedded into other plugins.
Is that roughly what you had in mind?

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