GNOME Bugzilla – Bug 343284
"Save as" not displaying file name the first time
Last modified: 2008-01-15 13:08:22 UTC
Please describe the problem: When I try to use "Save as" to save a decomposed (jpg) picture, the first time I call the "Save as" window, the file name is empty. The second time, the filename is filled. First and second times refer to times per specific picture, not per Gimp session. So for each new picture, it happens again. Steps to reproduce: 1. Open a picture 2. Convert it to B&W using "Filters -> Colors -> Decompose", choose "RGB", "Decompose to layers" 3. Tweak the picture (ex: flatten it) 4. Save the picture: "File -> Save as" Actual results: The "Save as" window does not contain the filename. If I click "Cancel" and open "File -> Save as" again, the filename is correctly displayed. Expected results: I would expect the filename to be displayed in the "Save as" window also the first time. Does this happen every time? Every time I decompose a new jpg picture and want to save it as {filename}-RGB.xcf It does not happen if I make other types of modification (resize, levels, etc.), only when decomposing. I didn't try other formats (only jpg). Other information: This problem happens with The Gimp 2.2.11 but also 2.2.8 and not with 2.0.4.
I use The Gimp on the Linux plateform (2.2.11 downloaded and compiled myself, 2.2.8 and earlier versions installed from RPMs).
What's the GTK+ version? The file chooser was fixed so often that the bug will probably go away up upgrading GTK+ to latest stable.
Hi! I upgraded GTK+ in order to be able to compile The Gimp 2.2.11. I installed the package gtk+ 2.0 version 2.6.4-2.2 from an RPM. So, you're suggesting I should install version 2.8.18 and see if the problem goes away?
Yes, please upgrade to the latest stable GTK+ release and report back.
Hi! I installed the lastest gtk+ version (2.8.18) and compiled Gimp 2.2.11 with it. The problem is now worse than before. Now, at step 4. (see above), the "Save as" window is systematically empty, no matter how many times I try. This happens after decomposition to layers, and not with a "simple" modification of a picture. Then the "save as" window gets the name of the file correctly and I can type any file name modification in there.
This happens because the save dialog uses gtk_file_chooser_set_uri() to set the name in the entry, which only works if a file with the specified uri already exists. The Gtk+ documentation suggests to use gtk_file_chooser_set_name() instead if no such file exists yet, but this function does no validity checking, so we would probably have to add some code in gimp_file_dialog_set_image() to handle this -- maybe just checking that the name does not begin with _("*Untitled") would be sufficient?
Hummm, well, maybe I read your message incorrectly and I have no clue how gtk_* are implemented but you say that the (original?) file may not exist ("[...] only works if a file with the specified uri already exists"). In the case I describe, I'm not dealing with a new or non-existing file since the problem I refer to happens when opening and modifying an existing picture. How could this file, with its uri, be "non-existing" then?
Okay, let's say you start by opening the file foo.jpg. This gives you an image whose name in GIMP is "foo.jpg". When you try "Save As", the proposed name is "foo.jpg", and that works, because there is an existing file with that name. Now suppose you decompose the image, let's say to RGB layers. The resulting image gets the GIMP name "foo-RGB.jpg". New when you select "Save As", the proposed name does not work, because no file with that name exists at that time. To be completely clear: you are not doing anything wrong. This is a bug, and should be fixed. My comment was aimed at explaining what causes the bug, and how we might go about fixing it, not at telling you how to deal with the situation.
I went ahead and added some debugging... Look at gimpfiledialog.c (gimp_file_dialog_set_image) It appears that gtk_file_chooser_set_uri() *always* returns TRUE, even if the file doesn't exist. As a consequence, the filename entry stays empty, because the file doesn't exist and our fallback code is never executed.
Oh... I get your point with "foo-RGB.jpg"... I was confused by the fact that the (existing) "foo.jpg" would suddenly, for some weird reason, become non-existing (no valid URI). But of course, "foo-RGB.jpg" does not exist (yet!). That also explains with tweaking a regular (non-decomposed) file creates no problem with "Save as". I was also confused by the fact that Gimp gives the name of the (future) file in the window title bar (i.e. "foo-RGB.jpg") and it was not clear to me why the file name would suddenly disappear. But now I get it. Thanks!
Just talked to federico. Apparently the return value of gtk_file_chooser_set_uri() is basically meaningless and the API docs are wrong. I think i have fixed the bug locally. Will test it some then commit to both branches.
Created attachment 67504 [details] [review] Patch fixing the bug This patch should fix it, by not asuming anything about return values and just always setting everything separately.
Comitted to both branches: 2006-06-16 Michael Natterer <mitch@gimp.org> * app/widgets/gimpfiledialog.c (gimp_file_dialog_set_image): always call gtk_file_chooser_set_current_folder_uri() and gtk_file_chooser_set_current_name() instead of gtk_file_chooser_set_uri(), since the latter only works if the file exists and its return value is bogus. Fixes bug #343284.