I wanted to add GtkFileChooserNative functionality to a program that can use the file chooser to select both existing and non-existing filenames, but neither GTK_FILE_CHOOSER_ACTION_OPEN nor GTK_FILE_CHOOSER_ACTION_SAVE are satisfactory for this program.
With the OPEN mode, the file chooser does not allow non-existent filenames, but otherwise performs well.
The only other file action available, the SAVE action, is troublesome to work with because the native file chooser fairly assumes that I actually want to save a file instead of opening them (in my case this means that it gets picky about confirming and “overwriting” existing files).
Is there any current way to have an equivalent to the OPEN mode but with the ability to input non-existent filenames? If not, then would it be possible at this stage to add a property that indicates to the native file chooser that it should not deny non-existent filenames?
I’d probably take a look at the actual UX here… Like, what’s the reason that it should allow both? Wouldn’t it be a bit confusing for the user?
That being said, you could maybe use a Save dialog and disable overwrite confirmation via gtk_file_chooser_set_do_overwrite_confirmation + a custom title + button name. I’d still take a look at the fundamental flow of your app if you need this, though.
Use case should be obvious I guess. When I am working with files I generally do in a shell:
cd myDir
gedit myFile.rb &
So if named file does not exists, a new one with that name is created, otherwise an existing one is opened. But there may exists users that generally are not working from inside a shell, maybe they launch their tool by a double click or from an “launcher”?
AFAIK opening files handled by the app’s .desktop file, which simply passes the file name as an argument. The program will simply try to create it, ignoring failure, and then open, or open the file with a mode that will automatically create it (e.g. a+).
Nothing magic is going on with regard to the dialogs.
(aside: have you been on the Python mailing list? Your username seems really familiar…)
The program in question is Emacs, so the UX isn’t really conventional.
It wouldn’t be confusing though: the user can either select an existing file to open, or “create” a new file to open in the selected buffer (window or sub-window). In non-GUI Emacs there’s no difference between the two, so it would be ideal if the file chooser could accommodate this behaviour.
This is actually how it is currently implemented with GtkFileChooserDialog, but the save mode doesn’t play nicely with my native file chooser (KDE’s) using GtkFileChooserNative, which is why I hoped there could be some workaround or API improvement to be made.
As an aside, explicitly disabling overwrite confirmation doesn’t make KDE’s portal file chooser disable overwrite confirmation… is this a limitation of GtkFileChooserNative or a bug on KDE’s side? I’m guessing the latter, but I’d like to double check before filing a bug over there.
My guess is that it might be intentional, to try to avoid apps potentially tricking someone into “opening” some sort of sensitive file that actually overwrites it.