GNOME Bugzilla – Bug 143011
Disable Open/Save button if filename is invalid
Last modified: 2015-08-05 22:23:43 UTC
When the typed name is empty, or invalid (such as '/' or 'foo/' or 'bar/foo' bar being a file) or not writable the save button should be insensitive. A label or something explaining why the button is sensitive might be useful as well as it might not be immediately obvious.
See bug #144232 for a related issue. We'll change the save dialog to support relative filenames shortly. For invalid filenames, though, we should definitely make the button insensitive. This is not as trivial as it seems, as GtkFileChooserDefault has no knowledge of the GtkDialog that wraps it.
For additional fun consider a filename with japanese characters on a latin1 filesystem...
We'll probably need a signal in GtkFileChooserEmbed, or somewhere, that GtkFileChooserDialog can pick up to decide if the typed name is valid or not.
Bug 162526 requests for gpdf that the save button should only be enabled if a file name has been provided. That is part of this bug. I'm not sure if I should duplicate it. I think that adding a signal (comment 3) means that gpdf has to implement/add that signal after this bug is fixed (so bug 162526 would depend on this one). Maybe GtkFileSel should always disable the button if the file selection is empty and use that signal only when a file name has been entered. If so, this bug can be limited to file name checking, while bug 162526 can be moved here for only the disable-button-on-no-filename part.
*** Bug 321122 has been marked as a duplicate of this bug. ***
In view of the age of this one , it's obviously not a high priority, however ... Enable/disable should probably be limited checking whether the entry is empty. Scurrying off to see if a name is valid to the fs in the case of save or if it exists (with access rights) in the case of open at EVERY key stroke sounds like overkill that will hinder keystroke response times in impair normal usage. A suitable "file does not exist" or "invalid file name" or "file not readable" would be most useful on selecting Open/Save. It seems the current behaviour (2.16.1) is to return the name whatever and let the client program handle the messaging. Rather than seeing Open/Save not being disable as a bug , I think it is a strategic interface question of whether it is the filechooser or the client program that should handle errors. There are probably arguments each way. It also links to how to handle wildcards: if I enter /zic/Clash and hit Open it navigates to that directory. If I enter /zic/Cla* it returns that string and the client fails to open it: it was asking for a filename.
We do always disable the button when the entry is empty, nowadays. And we silently trim leading or trailing spaces. And we interpret special names like ., .. or ~ by changing the location. So, I think this has been more or less addressed.
In 3.17, that is.