[RkWard-devel] Second 0.4.6 preview release, testing, translations

Thomas Friedrichsmeier thomas.friedrichsmeier at ruhr-uni-bochum.de
Sun Feb 11 18:33:19 UTC 2007


On Saturday 10 February 2007 21:10, Prasenjit Kapat wrote:
> I have been doing a few testing...

Thanks!

> [] Is there any particular reason for not providing the other options in
> read.table in "Further Options"? Like, quote, stringsAsFactor, flush.

No particular reason, no. I've added those three and allowEscapes. Hope we've 
covered everything, now (well, as.is is still missing, but it's hard to 
implement in a nice way, and stringsAsFactors should cover most real world 
use cases, I hope).

If you (and everybody else using the SVN version) can find some time, please 
test those options. I wouldn't feel to comfortable with including all these 
changes in 0.4.6, unless I know, they decent testing.

> [] After "Submit"ing why is the plugin still displayed? I got confused
> initially, as to whether or not the "Submit"tion actually worked. I guess,
> once the data has been read, the plugin should close. Again, I might be
> missing some subtle point!

Hm. Well, it is that way by design, though not necessarily by good design. The 
idea behind this is to make it easy to run the same thing again with only one 
or two parameters changed. Therefore the dialog does not close, when you 
press "Submit". On the other hand, maybe it's simply too confusing? Opinions?

> [] Vector of row/column names and vector of column classes: As the
> import_csv.rkh suggests, these need to be of the form
> c("var1","var2",..,"varn"). But existing character variable also works,
> right? (Yes, it does, I just checked) That is, instead of specifying the
> vector directly in the input box, I can just specify the name of an
> existing varaible which contains my list of row/column names. In that case,
> may be add a few lines to the rkh file, saying, "e.g c("var1",..,"varn") or
> an existing variable".

Ok, added a statement to that effect.

> [] Under the "Columns" tab, I think it is more appealing to include the
> input boxes inside the corresponding frames.

Done.

> [] In import_csv.rkh, some of the statements are missing a period in the
> end.

I hope, I've caught them all.

> [] In import_csv.rkh, the following line
>         c ("row1", "row2", ... "rown")
> should read
>         c ("row1", "row2", ..., "rown")
> What is the difference? A comma (.) after the ellipses. Similarly for the
> column name specs. Ha, I am just nitpicking. (This is what happens when you
> write too much of technical tex stuff :()

Well, it's always best to be correct, so it's good, you mentioned it.

> [] Should the "CSV" be renamed to something else, since the plugin provides
> option for "\t" or  ";" or "," or " " as  the separators? Maye be,
> File->Import Format->Read.Table ?

Well, CSV is not quite correct, technically (though you could simply read it 
as "Character Separated Values";) ). On the other hand, I don't 
think "Read.Table" would be too helpful a description. Changing it to Text / 
CSV for now.

> [] When on this, may be add another radio under "Feld Separator" as "Other"
> and an input box (enabled only for "Other") for any user defined separator?

Added.

> [] Now I am shooting wild: (Not for 0.4.6 release): Is it possible to
> provide a "preview" of the import much like what the various office suites
> (oocalc, kspread etc.) do, to let the user see what is actually
> happening/going to happen once the import is completed?

Hm, yes. This would be nice, but not exactly easy to do (but probably not 
impossible, either). I'll add it to the TODO list for now.

> [] This comment might make the plugin too complicated/confusing. What I was
> thinking is: add a dropbox under the "General" tab, which will decide a
> predetermined set of defaults for the various parameters. To be precise,
> the drop box, will include: None, CSV, CSV2, DLIM, DLIM2 which in turn will
> the set the paramters to the read.csv, read.csv2, read.dlim, read.dlim2
> respectively.
> 	Ok, though this is a thought of mine, but I am very uncomfortable with
> this being implemented (self contradicotry!). What do others think?

I don't think it's too useful in this particular case, since it basically just 
affects the two parameters "decimal point character" and "field separator 
character" which are directly available on the first tab (yes, it also 
affects some further parameters, but those two are the important ones). 
Probably, having those different defaults is more useful on the command line, 
than for a dialog. But what does everybody else think?

In general, I do kind of like this idea (but it gives me a slight headache, 
thinking how this could be implemented). Definitely something to keep in 
mind.

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


More information about the Rkward-devel mailing list