GtkFileDialog in `open` mode seems to ignore `:initial-folder`

TSIA really. Running the built in test:

tests/testfiledialog open --initial-folder '/tmp'

With action open, it always starts in Recent. But I don’t want that.

With action save, it starts at /tmp as I requested.

Is this a bug? The documentation doesn’t say it only works for save, and it should work for open. I simply want to let my user, upon opening a second file, start from the folder in which they selected the 1st (:initial-folder), and see that file being currently selected (:initial-name). This worked OK with FileChooserDialog.

I searched a bit more and found it is claimed to be a problem on the portal side, not GTK’s: Link

There Matthias said to try using GDK_DEBUG=no-portals (which was not documented, so I’ve just pushed a fix for that), but for myself and the issue OP apparently that makes no difference. So I’m not sure this is only a portal bug… or what else are we missing?

OK, GDK_DEBUG=no-portals does fix it when I run that test program directly, but not when I use it with my own app for some reason… ah well.

However, although in that case for open, the :initial-folder is reflected just fine, as is the folder part of the :initial-file - the :initial-(file|name) name component is ignored in open mode. I presume that is meant to work, and the reason it doesn’t currently scroll to / show the :initial-name is because of the list view widgets not supporting that yet (but hopefully will soon) - right?

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.