GtkFileChooser is missing callbacks for file extensions, putting userdata at risk.
Most applications that want the user to select a file for saving, make use of the do-overwrite-confirmation
property, and many of them also want to enforce a specific file name extension, which leads to a serious problem: Almost any developer invokes a GtkFileChooserDialog, checks and changes whatever he gets from gtk_file_chooser_get_filename()
then uses it. Now, if there's a file called "name.ext" in the current directory and the user types "name" in the FileChooser's entry, there will be no further inquiry, the file gets overwritten without warning. Currently the only way to circumvent this is to do all the checks yourself, then bringing up the dialog again if changes are needed.
The confirm-overwrite
signal is useless here, since it only gets emitted before the confirmation would be displayed anyway. I can see several ways to solve this problem. The easiest and probable most convenient would be to add another callback signal that gets emitted whenever a positive dialog response is intercepted, which would allow the application to do changes to the dialog before anything else is done. Another solution would be to allow the application access to the FileChooser's input widget, to do changes to it while the user is typing or as soon as it loses focus. That approach would allow for the highest level of customization, but might interfere with the dialog's internal logic. Least, the FileChooser could add functions to support in enforcing a specific file name extension directly. That would ensure a consistent user experience and be easy to implement for developers at the expense of possibilities for customized solutions. However, this approach could also be combined with one or both of the others by having some drop-in solution that could be used if no further customization is needed.