I want to show Windows users how innovative the GTK FileChooseDialog is, when when checking again, I am a bit frustrated because the dialog doesn’t accept remote file URI.
When I press Ctrl + L and pass a HTTP, SFTP URL, I expect the dialog to recognize it, but not.
Is this a design decision of GTK team, or just some unawared bug?
First of all, you may want to look at the value of the GtkFileChooser:local-only property.
Additionally, I’m not sure GIO—which is what we use to deal with local and remote files—supports SFTP on Windows like it does on Linux. As far as I know, GIO supports only local file: and http: URLs out of the box on Windows.
Found out that I discovered a bug. Even if local-only is set to false, if I paste this URL to FileChooserDialog http://www.moit.gov.vn/documents/40266/0/ap1.jpg/bfda943e-f879-4cc6-bca0-fe1095e586d3?t=1536553287861,
it will think that it is a local path and throw error:
That dialog looks like a Save dialog; saving into a remote volume is not something that’s usually possible unless there’s a ton more functionality, like authentication and network capabilities to upload a file.
As a general rule, applications needs to be able to handle URLs—typically by using GIO—in order to be able to open and save files to remote volumes.
It was opened as “Open” dialog, but due to this bug, it present as if it is “Save” dialog (please notice the green “Open” button).
Here is the Glade code: CoBang/data/main.glade at 2bdc35810a56e0b675570fd24c412b681b8089d5 · hongquan/CoBang · GitHub
The URL which reveals this bug has a “slash” after filename:
/ap1.jpg/bfda94
That is not how filenames work. This is a bfda94 file in a /ap2.jpg folder.
But do you agree that FileChooserDialog has problem judging this URL? Firefox can still open that URL, FileChooserDialog not.
I can reproduce the issue in the filechooser.
$ gio copy http://www.moit.gov.vn/documents/40266/0/ap1.jpg/bfda943e-f879-4cc6-bca0-fe1095e586d3?t=1536553287861 .
works fine, so this looks like a GTK bug indeed.
The file selection dialog does a bunch of validation checks; in this case, it is trying to get the file information and since it can’t, it is trying to recurse into the parent folder, and then fails again. The check is trying to catch things like selecting existing_file.txt/new-file.txt.
In practice, GtkFileChooserWidget is a massive state machine that makes a lot of assumptions, and it doesn’t deal very well with remote, complex URLs. We can probably fix some of this in GTK3, for instance by avoiding the recursive check if the entry contains a non-local URL. For GTK4, I’d rather nuke most of this stuff and replace it with a simplified widget.
FWIW, removing the ?t=… part gets it to work on my Linux box (tried with EOG): http://www.moit.gov.vn/documents/40266/0/ap1.jpg/bfda943e-f879-4cc6-bca0-fe1095e586d3. So there’s probably something bizarre going on somewhere indeed.
As a side note, GLib/GIO doesn’t have great URI handling API, yet. We’re working on a GUri API which would probably help handle additional fragments.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.