GNOME Bugzilla – Bug 695839
Save-as extension behavior is broken
Last modified: 2013-05-08 20:58:22 UTC
If I open, say, foo.gnumeric in v1.12.1 and then attempt a 'save-as', the 'Name' field of the dialog box will be "foo.". If I select a particular file-type and click the 'Save' button, a warning pops up informing me that the extension I've chosen is not consistent with the filetype and asks if I still want to proceed. If I click 'No' and then delete the trailing period in the Name field of the dialog box and click 'Save', the save works and the correct extension is supplied. This doesn't make a lot of sense to me and it's pretty annoying. If the name "foo" gets handled correctly, then "foo." also ought to work correctly, especially since that's what the program proposes when you initiate the 'save-as'
I cannot replicate this, but this looks like a gtk bug to me. Which excat version of gtk (or libgtk) are you using?
Note,that the problem is that you should not have "foo." but "foo" suggested. We understand "foo." to mean that you want the specified (namely empty) extension.
lrwxrwxrwx 1 root root 19 Feb 15 18:14 /usr/lib/libgtk-3.so -> libgtk-3.so.0.600.4 l gtk3 3.6.4-2 This is an up-to-date x86_64 Arch Linux system. Your point that "foo" should be proposed, not "foo.", make perfect sense and that, in fact, the handling of "foo." is correct. It just should not be proposed initially.
Hmm, we are doing: if (wb_uri != NULL) { char *basename = go_basename_from_uri (wb_uri); char *dot = basename ? strrchr (basename, '.') : NULL; gtk_file_chooser_set_uri (fsel, wb_uri); gtk_file_chooser_unselect_all (fsel); /* Remove extension. */ if (dot && dot != basename) *dot = 0; gtk_file_chooser_set_current_name (fsel, basename); g_free (basename); } This should set the correct name. Are you sure that your initial file name that you are saving does not happen to have 2 dots?
(In reply to comment #4) > Hmm, we are doing: > if (wb_uri != NULL) { > char *basename = go_basename_from_uri (wb_uri); > char *dot = basename ? strrchr (basename, '.') : NULL; > > gtk_file_chooser_set_uri (fsel, wb_uri); > gtk_file_chooser_unselect_all (fsel); > > /* Remove extension. */ > if (dot && dot != basename) > *dot = 0; > gtk_file_chooser_set_current_name (fsel, basename); > g_free (basename); > } > This should set the correct name. > > Are you sure that your initial file name that you are saving does not happen to > have 2 dots? Yes, I'm sure. BUT ... I just realized that I did not give you enough information to reproduce the problem. Do the following: Start gnumeric, fill a cell or two with random stuff and do a 'save as'. It will offer a name of 'Book1'. Select /tmp (I am assuming there are no spreadsheets of any format named Book1 in /tmp) and a file type of MS Excel 97/2000/XP. It will save /tmp/Book1.xls correctly. Now do another 'save as". it will offer the name 'Book1.xls'. Suppose now we want to save as a .odf file. Select, say, 'ODF 1.2 strict ...'. But to do the save, you have to manually change the extension to ods (the whole name is now 'Book1.ods'), or it will complain that the extension is inconsistent with the filetype. Do the save. Now try a third 'save as'. Now you will be offered 'Book1.' as the filename and trying to save as a gnumeric file will produce the behavior I described at first. Contrast with libreoffice. The first time you attempt a 'save as' it will offer a filename of 'Untitled 1'. Change it to 'Book1' (doesn't really matter, but let's do exactly the same thing we did above with gnumeric) and the directory to /tmp (I am assuming there are no spreadsheets of any format in /tmp). Do the save. The second time it will offer a filename of 'Book1' and save as an "ODF spreadsheet (.ods)" file. Do the save. Now try again. Same thing -- the filename is 'Book1' and you can save to any format you like, as many times as you like and it will always automatically generate the correct extension for you. This is the desired behavior, in my view. This whole thing came up because I usually use gnumeric, but had switched to libreoffice when version 1.12.0 of gnumeric appeared, because that version had some sort of problem that caused it to pause for a long time when attempting to quit, which was extremely annoying. When I booted my system this morning, I did a full Arch update (pacman -Syu), and gnumeric got updated to version 1.12.1. I tried it, and the 'quit' problem seemed to have been fixed. So I went to a spreadsheet that I have that contains a lot of useful information and that was then in .ods format. I pulled it into libreoffice and did a 'save as' in .xls format, not realizing that gnumeric now reads .ods format spreadsheets (I've moved spreadsheets for years between open/libreoffice and gnumeric using .xls as a common, interchange format). Now the directory where this spreadsheet lives had a foo.ods and a foo.xls. Then I started gnumeric, opened the .xls version with the intention of writing foo.gnumeric. That's when I came across this problem, because I was offered 'foo.' as the name. I apologize that the original report was incomplete and misleading. I didn't understand the situation clearly when I filed it (I thought I did; I think I do now, but perhaps I still don't :-).
I don't see what you experience: "It will save /tmp/Book1.xls correctly. Now do another 'save as". it will offer the name 'Book1.xls'." This does not happen to me and should not happen to you. For me it offers to save as 'Book1' as it should.
(In reply to comment #6) > I don't see what you experience: > > "It will save /tmp/Book1.xls correctly. Now do another 'save as". it will offer > the name 'Book1.xls'." > > This does not happen to me and should not happen to you. For me it offers to > save as 'Book1' as it should. Well, maybe it shouldn't be happening, but it is. What distribution are you using? It's certainly possible that there's a difference in library versions on our systems. As I mentioned earlier, I'm running this on an up-to-date Arch x86-64 system. Arch, of course, tends to be bleeding-edge, so I've got the latest bugs. I have a FreeBSD system I'm experimenting with and it has gnumeric 1.10.17. I tried the 'save as' scenario with this version and it behaves as you describe and as I would want. I also have Mint 14 installed on a netbook. It doesn't get used much and hasn't been updated in awhile. The current repository doesn't provide 1.12.x. I am updating the system now, hoping that 1.12.x will appear in the repository. This will take awhile, but if the new version does appear, I will test it and get back to you.
I still suspect that the behaviour of the combination of gtk_file_chooser_set_uri and gtk_file_chooser_set_current_name may have changed. I am running gtk 3.2 while other developers are using gtk 3.4 and none of us is seeing the issue.
The latest version of gtk is 3.6.4 and that's what Arch provides. FreeBSD does the same. You are two versions behind. You don't see that as a serious problem? I don't see how we can have a sensible discussion about this when you are using such an old version of a crucial library. If you look at the top five distributions on distrowatch.org, four of the five supply a version of gtk+ from the 3.6.x series (only Debian is behind, but they are always behind). As users, we are always told by developers "if you haven't upgraded to the latest version, I don't want to hear about your problems". This is the first time I've encountered developers of a major application who are using out-of-date versions of a major library. The last 3.2.x release was a year ago, and 3.4.4 was dated last July. I really feel like my time has been wasted here and I'm not going to put another moment into trying to help fix this problem.
My apologies for wasting your time, I will not do so any longer. For anybody interested in debugging this, I suspect that gtk bug #340835 may be related.
I'm at 3.6.0 (latest Mint) and I do see the problem. Recipe: 1. New Gnumeric. 2. A1=xyz 3. Save As 4. Select /tmp and Excel format. Save. (Book1.xls) 5. Save As 6. Change type to ODS --> Notice that filename doesn't change. (Irritating, if not terribly important) 7. Change filename to Book1.ods. Save. 8. Save As --> Observe "Book1." Note, that "." is selected. (Not good.) 9. Cancel. 10. From shell, do "touch /tmp/Book10.gnumeric" 11. Save As. --> Observe just "Book1". Off the top of my head this looks like it might be related to file name completion.
Ok, it's the completions. Evidently we are not using the file chooser in a Federico approved way anymore. Therefore, going forward, we should: A. Don't attempt to hide the extension in the file chooser. We aren't doing a very good job of hiding it anyway, considering that it is shown in the window title. B. For Save As we should initially set the old file name, foo.xls, for the user to edit. C. Not sure what we should do for a new file. I think we do the directory part of it right now, so that we should keep. D. When changing file format, adjust the extension so it matches the new format. That probably means changing to the first extension served by that format. (Always change?) Comments?
Created attachment 241744 [details] [review] Tentative patch Something like this. Please test.
This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.
I haven't tested it extensively, but the latest version in the Arch repository, 1.12.2, appears to have the fix. Thanks very much for taking care of this.