[RkWard-devel] Basic help system in SVN

[Thomas Friedrichsmeier]

On Monday 08 January 2007 19:29, SJR wrote:
> Great! How much use can be made of images?

You can add images using the regular HTML <img src="..."/>. Note the "/>" at 
the end, this needs to be valid XML, i.e. all tags need to be closed. The 
src-reference should always be relative. It is interpreted relative the 
whereever the .rkh-file is located (i.e. generally you'll write <img 
src="image.png"/>). Generally .png is the preferred file format. Image files 
are not yet added the distribution automatically, so please give me a note 
before the release, if you add images.

Please keep images to illustrate functionality, only, not for layouting or 
prettification purposes.

> Good news! Lately there are many updates of RKWard. I will try to find some
> time and places to announce it more general when the time for the release
> has come. Maybe Newsforge or ..., we will see. Certainly will will need
> some Updates of the translations.

Yes, but I intend to create a separate branch in SVN in a while, then wait for 
1 or 2 weeks during which only documentation, translation updates, and 
bugfixes will be allowed (but development can continue in the main branch). 
So it will be time to do the translations, then.

> There were some really bad mistakes in 
> the German translation (fixed some weeks ago) due to changes in the "core"
> of RKWard (possible?). The same applies to the french as far as I could
> see.

Actually, I don't really know, how
make package-messages
works internally. I know, that it tries to keep translations, where strings 
have only changed slightly (a good thing). Probably somehow something bad 
happened, here, but I don't know how to avoid this.

> Feature freeze since last week here. I planed to add round() to the
> distribution plug-ins (the output is awefull to read right now if a vector
> of data is entered) but this would require some time and therefore I'll
> postpone it to the next release.

round () probably is not the right way to do it though. Or rather, this should 
be a matter of the output routines, not something you do to the results to 
make them prettier. We could probably round all printed results to a certain 
number of digits right now, but the downside is, that then the precision will 
be lost for good, even if you happen to need it.

One of the long term TODOs is to find a way for the user to adjust the 
*displayed* precision on the fly, while the full precision would always be 
stored in the output. That's easier said then done, however...

> Great, good that you follow practices as other projects have.

I'm trying to get there...

> Regarding bug fixes. I think it would be beneficial to have some kind of
> test suite/tools (as other software project (Gnumeric for handling of
> XLS-files e.g.) have. This could be for example set of data or functions to
> be used before every new release. By using them everybody could
> semi-automatically test RKWard. Of course not for this or the next release
> but for those in future. I'm not aware if something exists for R (I doubt
> that). More precise, a test suite could consist of set of data which are
> known to be difficult to handle (size 32k -> 64k e.g.? or whatever) in
> combination with typical workflow scenarios (start plug-in see if required
> packes are loaded, test if logic makes sense ...). Or some kind of check
> list one has to go through before a plug-in is officially is released. This
> would be even more important when new contributors commit changes. I long
> term it's maybe impractical to expect that you (Thomas) will have the time
> to check each plug-in bit for bit.
> After all RKWard is aimed to be used in science and there is nothing more
> worse than a tool that produces faulty results (something that RKward
> doesn't do right now of course ;) ). I guess you know what I mean. I will
> try to come up with some thought but right now I have no idea how to design
> something. To be honest a rather difficult and complex task if not even
> impossible to realize.

All true. But in fact, the problem is, how to do this right. One thing that 
might help in this task would be, if it was possible to run plugins 
programatically from R code (the settings to be chosen in the GUI would be 
given as pairs of id->value). Well, still not easy to do.

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