[RkWard-devel] need a little help..

Thomas Friedrichsmeier thomas.friedrichsmeier at ruhr-uni-bochum.de
Thu Mar 22 21:14:06 UTC 2007


On Thursday 22 March 2007 20:39, Prasenjit Kapat wrote:
> Can you check the indentation for F/t/Weibull now? If things are ok the I
> will change the other CLT plugins too. Lets get ONE CLT plugin perfect
> first!

- The closing '})' of the try() is indented, but shouldn't be
- In F and Weibull, the
	if ($fun == "hist)
is indented by two spaces instead of a tab
-  the line
	else	$normMuSigma_tag = ...
has a tab after the else, instead of a space.

Talking about perfection, though - will we ever get there? I just found 
another small thing which is copied in all plugins, and we've never noticed, 
while we've all seen it: "Nomral Curve Options" -> "Normal Curve Options".

Also, while I went through the other distribution plugins (probabilities, 
quantiles, plots) to clean up usages of "rk.temp" and "cleanup()", I had 
another shocking thought. See the end of this mail.

> > 3) The logic to ensure df > 2 is neat, but I don't think it's needed.
> > Just set min="2.0001" in the spinbox, and explain the limitation in the
> > rkh (as you've already done).
>
> I am looking at it this way: As it is now, the user gets to know the exact
> issue right away. There is already some empty GUI space which can be used
> to provide some more information without needing the user to refer to the
> help file. I feel this is more transparent.

I see. What I feel is a bit strange about this, however, is that you "allow" 
to chose a bad value in the spinbox, and then disallow this again in a second 
step. As another option, maybe put up a static "note" to the same effect in 
that unused space, instead of a dynamic error message, and limit the range of 
the spinbox.

That said, either way is fine with me, so pick whatever you like best.

>  Again lets make ONE plugin immaculate first!

Ok, here's that idea I had a little too late. Perhaps it's not worth the 
effort to change this at this point, but here it is:

The plugins are all very similar, internally, and in fact, much of it is 
copy-and-paste. Right now the problem is that every little issue we find 
likely needs fixing in all plugins. And if we want to add some extensions 
later on, or change e.g. the try() statements, likely we'll have to visit all 
plugins one by one, again. So could we use more common code, instead of 
writing basically the same, everywhere? I think we could.

I'm attaching two PHP files. The one is called plot_clt_common.php and 
contains everything that is common for all clt plugins. This would be 
included in all "real" clt plugins. The second is what plot_t_clt.php would 
then look like. What do you think, should we do it this way?

Note that a lot of the XML is also the same in all plugins, but right now I 
don't see any good way to abstract all the common parts there, beyond what 
you already do by embedding the histogram_options and plot_stepfun_options 
plugins.

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: plot_t_clt.php
Type: application/x-php
Size: 606 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20070322/65b65f18/attachment.php>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: plot_clt_common.php
Type: application/x-php
Size: 2566 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20070322/65b65f18/attachment-0001.php>
-------------- 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/20070322/65b65f18/attachment.sig>


More information about the Rkward-devel mailing list