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 427806 - Crash: when specifying an invalid extension in save as dialog
Crash: when specifying an invalid extension in save as dialog
Status: RESOLVED FIXED
Product: eog
Classification: Core
Component: general
git master
Other Linux
: Normal major
: ---
Assigned To: EOG Maintainers
EOG Maintainers
: 457168 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-04-09 10:02 UTC by Jaap A. Haitsma
Modified: 2007-08-13 15:42 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
WIP-Patch to display an error box (1.76 KB, patch)
2007-08-09 10:10 UTC, Felix Riemann
none Details | Review

Description Jaap A. Haitsma 2007-04-09 10:02:24 UTC
Specify for example  image.blah and eog crashes. This is because gdk-pixbuf does not understand the .blah extension
Comment 1 Felix Riemann 2007-04-12 10:29:34 UTC
Confirming.

"Older" EOG versions displayed a notification in that case that allowed you to return to the SaveAs dialog or completely cancel the operation.
Comment 2 Jaap A. Haitsma 2007-04-12 18:51:22 UTC
Is that also the desired behavior of the new EOG??

What if a user does not specify an extension? Automatically append the extension of the original file??
Comment 3 Claudio Saavedra 2007-04-12 20:50:53 UTC
Not specifying an extension is equivalent to specifying an unknown one if, let's say, the user wants to save her picture as "alice.peters", for example. I think that using the format of the original file and appending its extension, if the given one is not known (or missing), would be nice. Users should not be forced to know about image formats in order to save their pictures.
Comment 4 Felix Riemann 2007-04-14 09:24:19 UTC
(In reply to comment #3)
> I think that using the format of the original file and appending its extension,
> if the given one is not known (or missing), would be nice.

Yes, that would be nice. But unfortunately we support more formats for loading than for saving. For example we support loading TGA files but we currently cannot save them.

Comment 5 Felix Riemann 2007-07-17 07:23:25 UTC
*** Bug 457168 has been marked as a duplicate of this bug. ***
Comment 6 Felix Riemann 2007-08-06 16:28:48 UTC
Another idea I just had:
In case of an unknown extension or none at all we could append ".png" to the filename and save the file in PNG format. This would only loose the metadata and preserve the image quality.
Comment 7 Jaap A. Haitsma 2007-08-06 16:41:03 UTC
In that case I would go for jpg. Users in general will be more familiar with that format
Comment 8 Felix Riemann 2007-08-09 10:10:29 UTC
Created attachment 93346 [details] [review]
WIP-Patch to display an error box

So, this is a work in progress patch.
It simply checks if the fileformat is fine and displays an error if not.
The filechooser is kept open and allows immediate improvement of the filename.

I'd really like to get some input on what text we should put inside the error dialog (I'm not really creative in such things). :-)

I'm planning to get this in for 2.20. Maybe this can be improved to allow choosing the fileformat from the error box in the next cycle.
Comment 9 Claudio Saavedra 2007-08-09 15:10:44 UTC
Patch works good. I'd simplify a bit the wording and remove the "!" to make it a bit more friendly. Something like: 

"Could not determine file format.

The file format you entered is not supported. Please try a different file extension, like png, or jpg"

Either way, wouldn't be better to use the EogMessageArea instead of a dialog? The disadvantage would be that we would need to close and reopen the save dialog, but maybe that's a more consistent approach with current eog. In that case, a "cancel"/"retry" would be needed.


I agree we need to fix this Real Soon Now (tm).
Comment 10 Felix Riemann 2007-08-09 15:53:02 UTC
(In reply to comment #9)
> 
> Either way, wouldn't be better to use the EogMessageArea instead of a dialog?
> The disadvantage would be that we would need to close and reopen the save
> dialog, but maybe that's a more consistent approach with current eog. In that
> case, a "cancel"/"retry" would be needed.
> 

I thought about that too, but I think sooner or later we could have the user choose a supported file format from that dialog (if he used an unsupported one) and have the extension appended automatically. This moves it into a role similar to the overwrite confirmation dialog, which is why I chose the current approach.

It also has the advantage that it allows easy editing of the filename. If we cancel the whole operation would have to enter the filename from the beginning, which could involve extensive directory crawling.
Comment 11 Claudio Saavedra 2007-08-09 16:03:23 UTC
Sounds reasonable. For me, you can go ahead :-)
Comment 12 Claudio Saavedra 2007-08-09 20:51:13 UTC
FWIW, Lucas agrees with your approach, so go, go, go!
Comment 13 Jaap A. Haitsma 2007-08-09 21:09:44 UTC
Two small text remarks: 

file format i.s.o. fileformat

As title I would go for: "Cannot save file!" or something like that. 
Comment 14 Felix Riemann 2007-08-10 12:43:48 UTC
I took some other text now:
"File format is unknown or unsupported"
"Eye of GNOME could not determine a supported writable file format based on the filename.
Please try a different file extension like .png or .jpg."

I think this resembles better what the HIG expects from en error dialog, but thanks for the ideas. :-)

{UI,String}-Change-Announcement will be sent out soonish.

----
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.
Comment 15 Reinout van Schouwen 2007-08-13 11:22:16 UTC
As Claudio says in comment #3, users shouldn't be forced to know about image formats in order to save their images. So I object to Felix' error dialog.

One could argue that the user should be pointed to the file format filter dropdown box in the filechooser, but this box is visible only when the user has expanded it, and then still it's unobvious.

Instead I propose to "do the right thing" and select a proper extension when the user didn't specify it. Is it possible to detect whether an image is likely a photograph or line art? Perhaps GIMP or Inkscape already contain such an algorithm and it could be used to choose either PNG or JPG. If it's too difficult then we should go for the lossless option, namely PNG.
Comment 16 Claudio Saavedra 2007-08-13 15:42:09 UTC
Reinout, 

The specific problem here (the crasher) has been fixed. There's still room for improvement regarding how to handle unknown/missing file formats, but I would suggest opening a new bug to track that.

FWIW, in the GTK+ meeting at GUADEC it was proposed to have a "file type selector" for the "save" version of the filechooser. Probably in with 2.14. Maybe that could help.