Bug 217598

There was a problem about the old behaviour: themoment the options that are special to a selected file type (like jpeg compression) are displayed directly inside the save dialog. If, eg. the dialog initially states tiff, you change the extension to jpeg in the filename and save the file with automatic file type detection based on the extension, you end up with unpredictable options for the generated jpeg, because you never saw the options for jpeg in the dialog.

I think there are two solutions to solve this problem if and automatic detection based on the filename is needed:

1. doing the automatic detection while typing the filename and adjusting the file type settings every time a new type is detected by the extension. But this could result in strange flickering of the dialog while typing.
2. Use two step procedure: First type the file name and after confirming the dialog show a separate window with file type specific options. This is the way gimp does it. I don't like it too much, because you always have to confirm two dialogs.

In the two-stage procedure you suggest, the second dialog is only necessary if the filter and the name from the first dialog contradict each other.

We could also simply attach the correct extension, so if I selected jpeg, but type bla.tiff, the file would be saved as bla.tiff.jpg. I aggree, this is ugly, but that way digikam would at least be able to open the file again, which it is not with the current behaviour.

At least I should be warned, if I try to save a 16Bit image in a 8Bit format.

I dont like the two-dialog approach.
The autodetection thing is how I would expect this to work; can the KDE file dialog do this?

I just tried a bit with the "options-while-typing" solution. It works better than I thought and we could use this one. The problem there is that this solution would completely ignore the filter selected.

My proposal would be to use the filename extension if the filter "all images" is selected and display the file format options immediately while typing after it is detected.

If any other filter is selected, use that format.

What do you think about this?

(In reply to comment #3)
> The autodetection thing is how I would expect this to work; can the KDE file
> dialog do this?

It's not much work. Could be don in half an hour for me. ;)

The only thing I see with my proposal above is that the filter "all images" should be changed to "all images (use extension for format)", but we're in the string freeze now... Can we break for this or should we wait with the string change after 1.0 release?

I don't like twice dialog solution too..

You can break i18n if you please kde translators team sending a mail to the mailing list. also, i18n changes must be small of course.

Gilles Caulier

Ok, so do you think that solution I proposed is good?

yes, it's fine for me...

Gilles

SVN commit 1060041 by jwienke:

Detect save file type based on file name of "all images" filter is selected. Otherwise use filter type.

BUG: 217598

 M  +129 -18   libs/widgets/common/filesaveoptionsbox.cpp  
 M  +47 -2     libs/widgets/common/filesaveoptionsbox.h  
 M  +13 -0     tests/CMakeLists.txt  
 AM            tests/filesaveoptionsboxtest.cpp   [License: GPL (v2+)]
 AM            tests/filesaveoptionsboxtest.h   [License: GPL (v2+)]
 M  +44 -51    utilities/imageeditor/editor/editorwindow.cpp  
 M  +5 -3      utilities/imageeditor/editor/editorwindow.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1060041

Under Windows the two step solution is needed since the Save as dialog is the native Windows dialog. Is it hard to do? I could try it myself if someone could give me some hints on where to start.

Gilles, what do you think? I never tried digikam on windows?

Yes, under windows, Qt file dialog is used instead KDE filesave dialog. But i think it's a temporary solution...

Here Patrick can respond better than me about this situation...

Gilles