After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 143846 - Gnumeric implements Excel's mistakes when saving CSV files
Gnumeric implements Excel's mistakes when saving CSV files
Status: RESOLVED WONTFIX
Product: Gnumeric
Classification: Applications
Component: import/export Text
1.2.x
Other Linux
: Normal normal
: ---
Assigned To: Jody Goldberg
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2004-06-07 05:20 UTC by Uri David Akavia
Modified: 2005-01-08 17:50 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Uri David Akavia 2004-06-07 05:20:45 UTC
Open an existing CSV file.
Edit it.
Click save.
Get a dialogue asking you to save as Gnumeric file.

Expected result - the CSV file is saved, unless you press "Save as...". If you
have added funcionality that isn't imported to CSV (and only if, not as a
standard policy) Gnumeric warns you that might lose functionality (preferably
telling you what functionality you'll be missing).

I know how to use CSV files. That's why I saved the original data (before
Gnumeric) in a CSV file.

To me, it feels too much like the problems Excel causes when you try to save an
editted CSV file. To see the problems in Gnumeric, save the file as a CSV file.
Then quit Gnumeric (without touching the file). You get another dialogue
requesting you to save.
Expected result here - if you have saved (in CSV or otherwise) Gnumeric quits
without saying anything.

This is actually two bugs, but they are very similar. If you want, I'll open two
different bugzilla entries.
Comment 1 Andreas J. Guelzow 2004-06-07 13:11:56 UTC
I believe that more users use csv files to import data into gnumeric than to
keep their data in that format. (With XL there might have been a reason not to
store data in a proprietary format but this is not the case with gnumeric). Once
data has been imported  from an csv file, the average user will have added
information that is not stored in csv so a warning as above would just be highly
annoying. THe normal action should be to save the information in a proper spread
sheet format.
Comment 2 Uri David Akavia 2004-06-07 20:20:34 UTC
I believe you're wrong, in several aspects.

There are reasons to use CSV - it is a text format that contains only the data,
which means it is smaller than most other formats. (Definitely smaller than XL)
It is compatible with Excel, unlike Gnumeric.
It is a very simple file format, so it is easy to use in Scripts via simple text
processing.


As regards to the inconvinience, let's try to examine it.

Current situation
-----------------
A user that opens a CSV file and intends to save it as a Gnumeric file. He opens
the CSV, changes it. Saves at some point.
When saving he reaches the "Save as" dialog, in it he has to select the file
format and the name.
This user meets the "Save as" dialog once.

A user that wishes the CSV to stay a CSV file.
He opens the CSV, but he meets the "Save as" dialog EVERY SINGLE TIME he saves.
Every time he meets the "Save as" dialog, he has at least one more step than the
previous user - he selects the file that already exists, and confirms
overwriting it. (again and again, ad nausem).


Having an Error dialog about the problems of CSV
------------------------------------------------
(Possible dialog - the CSV file format does not support graphs or formulas. 
We reccomend that you save in other formats. Would you like to save in a CSV
format? Yes/No/Cancel)

A user who wishes to convert CSV to Gnumeric.
He tries to save once, reaches the error dialog, and presses No or Cancel. This
returns him to the sheet, and he selects Save as command. Normal interaction
with the "Save as..." dialogue.

Addition to his work - one error dialog, one specific selection of "save as"
instead of save. Possible ways of speeding this up - if the user selects "No" in
the error dialog, the "Save as..." dialog opens automagically.


A user who wishes not to convert CSV.
Every time he presses save, he has to select Yes.
Time saved - the time needed to interact with the "save as..." dialog (which can
be considerable).
Possible way of streamlining - if Yes is selected at one time, do not show this
error again for this sheet in this session.


Conclusion - This error dialog saves time, it doesn't waste it.
Comment 3 Andreas J. Guelzow 2004-11-14 17:47:55 UTC
Regarding the user who wishes not to convert to CSV: 

The interaction with the "save...as" dialog should not be considerable: S/he
should only need to select csv format and click okay. Everything else should be
set-up correctly. 

So what this proposal does is move one required action from the user who wants
to save as csv to the user who doesn't, with the potential of loosing
information for the latter if they click okay in the error dialog but some
formatting or content is lost.

Since you belong to the former group I can see why you would prefer sucha
change, but it doesn't look like it is going to happen.
Comment 4 Uri David Akavia 2005-01-08 17:50:15 UTC
I have seen your comments - would it be difficult to have Gnumeric remember the
format last saved, so I will only jave to interact with the "Save As" dialog once?

I use Excel at work (and home), Gnumeric at home. When I am using CSV files,
Gnumeric *feels* much slower.
I have no idea if it actually takes more time than Excel, but I suspect so.

Changing Gnumeric a bit, since you are opposed to the error dialog, so it will
remember the format once, will speed things up.