Re: [Gretl-devel] CVS news
Am 19.01.2014 15:15, schrieb Allin Cottrell:
2. Binary data files: I've now implemented Jack's suggestion in
http://lists.wfu.edu/pipermail/gretl-devel/2014-January/004872.html
So here's how things stand: the --binary option to "store" is gone;
instead, to save data as binary, use the new ".gdtb" filename
extension, as in
store foo.gdtb <optional-series-list>
This results in creation of a zip file containing data.xml
(metadata) and data.bin (binary component).
Is that literally "data" in the name always? The alternative would be
"foo" I guess -- although the user doesn't normally get to see these
names anyway, right?
The binary data option is not yet fully represented in the GUI.
Before I do that I'd like to get reactions to a suggestion.
Obviously, adding a new native datafile type will complicate the GUI
somewhat. At the same time I'd like to remove some old complexity
that I think is no longer needed.
Under the menu "/File/Open data" we have both "User file", which
leads to a file selector equipped with a long list of file types
(both native and "import" formats) and an "import" item which lists
the supported import formats. I'd like to get rid of the "import"
item since it really just repeats in a different form what's
available under "User file". And similarly for the "Append data"
menu: I'd like to switch to a single file selector with a drop-down
list of filters.
Yes I like that, although...
There's one possible downside of this, but I doubt that it's a real
issue. That is, suppose one has a misnamed file (e.g. a plain text
file with ".xls" extension). In principle you could handle this by
selecting "text/CSV" from the current import menu (hence forcing the
interpretation of the file) and then using the "All files" filter in
the dialog, or manually typing the spurious filename. The option of
pre-forcing the interpretation of a file regardless of its name
would be gone under my suggestion. But how many users have ever done
this sort of thing? (Besides, this is a work-around for a problem
that has an obvious and simple correct solution: rename the file in
question. If you're smart enough to figure out that the "import"
menu allows you to work around broken filenames, you're smart enough
to fix the file!)
Well, being a veteran Mac user (not much OS X use, though) I remember
Apple's philosophy that metadata of a file is more than just the
extension, thus it was stored differently (does the "resource fork" of a
file still exist on Mac?), and thus typically Mac files did not have an
extension. Actually the same has always been true on Unix, no?
(/var/log/messages anyone?)
So I think the problem is not really misnamed files, but the ones that
deliberately do not have an extension. I wouldn't consider these broken,
and thus IMHO gretl would need to deal with that. Perhaps a greyed-out
drop-down list of file formats that only becomes activated when the *.*
filter is chosen.
cheers,
sven