Opened 12 years ago

Closed 12 years ago

Last modified 11 years ago

#9917 closed defect (fixed)

File save dialog does not honor file extension on GTK

Reported by: oneeyeman Owned by:
Priority: normal Milestone:
Component: wxGTK Version: stable-latest
Keywords: wxFileDialog wxGTK Cc: roebling
Blocked By: Blocking: #11256
Patch: no

Description

Steps to reproduce:

  1. Run "dialogs" sample.
  2. Choose "File Save" dialog
  3. In the "File Name" enter some name, for example "test".
  4. Hit Enter.

The file name displayed will be "<current_dir>/test".

If you run the same steps on MSW, the file name will be
"<current_dir>/test.doc"

Change History (14)

comment:1 Changed 12 years ago by vadz

  • Resolution set to fixed
  • Status changed from new to closed

Seems to have been fixed by Robert (should this be backported to 2.8?)

comment:2 follow-up: Changed 12 years ago by wojdyr

I don't know if forcing file extensions was the right thing to do.
The native behaviour on Windows is to silently add the extension, and on GTK it is to leave the filename as it is.
IMO changing wxGTK file dialog to work like on MSW will rather confuse users.

comment:3 in reply to: ↑ 2 Changed 12 years ago by oneeyeman

Replying to wojdyr:

I don't know if forcing file extensions was the right thing to do.
The native behaviour on Windows is to silently add the extension, and on GTK it is to leave the filename as it is.
IMO changing wxGTK file dialog to work like on MSW will rather confuse users.

Marcin,
Then depending on the platform user code runs, he should be writing the #ifdef statements. I believe that's what we all are trying to avoid here.
So, if we decide to revert this, we should clearly document this behavioral difference.

Also, what this dialog do on Mac?

comment:4 follow-up: Changed 12 years ago by vadz

  • Cc roebling added
  • Resolution fixed deleted
  • Status changed from closed to reopened

Robert, does it actually behave now as Marcin wrote? If so, I definitely agree that this should be reverted.

If the user types foo in the file text box, the file should be named foo, it's incredibly aggravating that Windows insists on making it foo.txt (assuming the default extension is .txt) and you have to type foo. or "foo" to call it like this and we definitely don't want to annoy Unix users like this.

In reply to the last comment, I don't understand why should the program have any #ifdefs, it should just use the file name that the user provided, whatever it is.

comment:5 in reply to: ↑ 4 Changed 12 years ago by oneeyeman

Replying to vadz:

Robert, does it actually behave now as Marcin wrote? If so, I definitely agree that this should be reverted.

If the user types foo in the file text box, the file should be named foo, it's incredibly aggravating that Windows insists on making it foo.txt (assuming the default extension is .txt) and you have to type foo. or "foo" to call it like this and we definitely don't want to annoy Unix users like this.

Then what is the purpose of having the "default extension" field in this dialog? AFAICT, MS put it there to simplify the user life, so that they won't have to type the extension in the filename. It is also easier, I guess, because it will allow programmers to register/associate the extension with the program to open the file.

In reply to the last comment, I don't understand why should the program have any #ifdefs, it should just use the file name that the user provided, whatever it is.

Exactly because people on Windows expects it to be added to the file name and if I want the name of the file to be <my_file.txt>, I can simply use "default extension" field to put it this way. I don't have to expect the same knoweledge from the user of my program.
However, if this patch will be reverted, than the programmer will have to do something like this:

wxFileDialog dlg(...);
if( dlg.ShowModal() == wxIDOK )
{

wxString name = dlg.GetPath();

#ifdef WXGTK

name += dlg.GetExtension();

#endif
}

But that behavior was not documented anywhere, that's why I wanted this to be fixed.
OTOH, if we decide to revert this patch, then this difference has to be documented, so that next person that will say "it is a bug" could be referred to the docs.

Thank you.

comment:6 Changed 12 years ago by vadz

The default extension is the one which is selected by default in the file type combobox so it's still not useful.

And using #ifdef like this makes no sense, clearly a user can also enter a file name without extension under Windows as well as enter it with extension under Unix. If you really need the file to have this extension you should, unsurprisingly, test that it does have this extension but in fact it's much better to not do it and just use the file name that the user provided.

comment:7 follow-up: Changed 12 years ago by oneeyeman

Vadim,
Open "Notepad", then select "File->Save As..."
"Save as type:" field will say "Text document (*.txt)". This means that every file you save will have an extension ".txt", even if you supply an extension yourself.
When you open this combo box you will see the second choice: "All Files". It means that whatever you type as the file name, the file will be named.

If you still think that this field is worthless for file save dialog, please go argue about this to MS ;-)
I think it simplifies the life of the programmer, since the user of the program won't ever care about some file extensions. He will just hit "Save" or "Save As..." and will expect from the program to do the right thing. And for Windows, people will expect to have file extension, that will match whatever file extension was selected in the "Save as type:" combo box.

Now, I do understand that it's not the way native GTK app behave. However, nowhere on the wx docs I could find that I need to perform such check if using wxGTK (see my code example in the previous reply. BTW, do you have an example of how to perform this procedure?) At least wx programmer has to know about such differences between ports, wouldn't you agree?

comment:8 in reply to: ↑ 7 Changed 12 years ago by vadz

Replying to oneeyeman:

Vadim,
Open "Notepad", then select "File->Save As..."
"Save as type:" field will say "Text document (*.txt)". This means that every file you save will have an extension ".txt", even if you supply an extension yourself.

This is false as I wrote in the comment:4. You can specify a different extension by taking the file name in quotes. Why don't you read what I actually write?

Now, I do understand that it's not the way native GTK app behave. However, nowhere on the wx docs I could find that I need to perform such check if using wxGTK

You do not need to perform this check. If the user wants to save a text file as "virus.exe" you should let him do it and don't attempt to second-gues it.

Robert, I don't know what exactly the change was but could it be please reverted? It seems quite clear that the motivation for it was completely misguided. Thanks!

comment:9 follow-up: Changed 12 years ago by roebling

  • Resolution set to fixed
  • Status changed from reopened to closed

If create a document with OpenOffice under Linux and save it to disk, it will adopt the default extension suggested by the OpenOffice save dialog if you only type the filename. If you yourself type a full name with a different extension, it will use that instead. that is what my patch does. That is what wxFileDialog has been doing during the last ten years. I won't revert the patch.

comment:10 in reply to: ↑ 9 Changed 12 years ago by vadz

Replying to roebling:

If create a document with OpenOffice under Linux and save it to disk, it will adopt the default extension suggested by the OpenOffice save dialog if you only type the filename.

OO is not the brightest example of native behaviour but well.

If you yourself type a full name with a different extension, it will use that instead. that is what my patch does.

This is the correct behaviour, I have nothing against it. I just don't want this extension to be 'always' used as oneeyeman apparently seemed to want.

That is what wxFileDialog has been doing during the last ten years. I won't revert the patch.

Sorry, I don't understand this at all. If it was doing this since 10 years, what did your patch really change? Do you have a link to the revision with this change?

Anyhow, I tested the dialogs sample and everything seems to work correctly.

comment:11 Changed 12 years ago by oneeyeman

Vadim,
I guess you misinterpreted my words.
I'm perfectly happy with what Robert's change does. All I was trying to say that if the user didn't supply an extension than the dialog should add the extension that was selected automatically.
Besides I don't know about everybody else, but I never supply an extension in the file name of this dialog. I always rely on the dialog doing the right thing and that it will add the extension for me.
Rev 55350 is what you are looking for. This revision fixed the bug.

Thank you.

comment:12 Changed 12 years ago by roebling

Vadim asked:

Sorry, I don't understand this at all. If it was doing this since
10 years, what did your patch really change? Do you have a link to
the revision with this change?

I don't know exactly, but I think the old behaviour was broken
when starting to use the new wxGtkFileChooser class.

comment:13 Changed 11 years ago by oneeyeman

  • Blocking 11256 added

(In #11256) The second changeset re-introduces 9917, which was fixed about a year ago.
At that time Vadim agreed on the fix, however currently he's saying that this bugfix second changeset is intentional.

Thank you.

comment:14 Changed 11 years ago by vadz

I agreed to the fix because of Robert's insistence that it was the right thing to do, I was opposed to it initially and now I just feel vindicated in this: always appending the default extension is definitely wrong, whatever OO does (although I didn't test it actually so maybe it does the right thing).

Again, under MSW you can prevent the default extension from being added by either selecting a different one from the file types combobox or by quoting the file name. Under GTK there is no such possibility and hence the default extension should not be added.

To summarize, there is no problem here, each platform behaves as it should now.

Note: See TracTickets for help on using tickets.