I thought there was a specific reason why we had decided this was a bad idea. @Gol-D-Ace or @kkartaltepe might remember.

Doing this will reduce functionality on GTK.
Especially network shares will not be accessible anymore through the GUI.

I already had complaint's when doing that from users and reverted a different workaround.

On the other hand flatpak and co default to the qt widgets shrug

This is just a stop-gap measure until the actual issue is fixed, so it is better than nothing.

Doing this will reduce functionality on GTK.
Especially network shares will not be accessible anymore through the GUI.

If the choice is between "no browser sources on any Linux build" vs. "no ability to load files from network shares when using GTK" then I feel like the browser source should win out in this scenario, personally.

Would network shares still work with a manually-typed or copy/pasted path?

Anyone have both Linux and access to network drives via Linux? If so could you pull and test to see if network paths work when manually typed in or pasted in to the dialog?

At least on my machine this doesnt affect any of the file dialogs (e.g. on gnome they still load the gnome file browsers)

Additional info:
Network shares should be still reachable from the mount location (on Ubuntu for example /run/user/$UID/gvfs)

Same with USB and other drives.

On the standard Ubuntu flavor this PR worked fine. Tomorrow I will try MATE.

Also working fine with Ubuntu MATE.
@kkartaltepe Do you have the qtconfig tool installed? It can override the default behavior (not sure if it can/should with this change though).

Both without qt config tool and with it the behavior was unchanged. After uninstalling nautilus the qt file picker showed up, and after reinstalling nautilus it stayed qt file picker... Even on master.

Is it known when 25.0.9 will be released with this change?

So with the merge of this, is this coming in a 25.0.9 release? And if so, when-ish?

This will be officially released with the next major update (v26) in the next few weeks.

That sucks :/ last major version release (v24) was Sept 2019. What good is having minor revision numbering if you can't even use it for something like this?

...What? Last major release was v25 in March 2020.

You make a lot of assumptions about what should or shouldn't be done or what goes in to a release, whether it be patch, minor, or major, especially considering how much as already been pushed to the master branch.

Please cease that discussion on our repositories. If you want to express your discontent, you can do it on discord or something. The repository is not the place for it.

Did you miss the part where I said v24? Yes, v25 March 2020, v24 Sept 2019. Suggests to me that I'm waiting a long while (probably) for v26. Which is why I'm trying to make the case for a 25.0.9 for this fix. Again, why even have a numbering convention with 25.x.8 if the project isn't even going to use the x, or the minor minor release?

Discord isn't a publicly indexed space. Github is. I don't see why discussion is unacceptable in this space, but whatever dudes. I've said my bit.