The way I mostly deal with the open filepicker is just drag and drop a file in there. In Windows, this tries to copy the file to the location, which is an insan

The way I mostly deal with the open filepicker is just drag and drop a file in there. In Windows, this tries to copy the file to the location, which is an insane thing for a filepicker to do: in gtk, this just shows the file and selects it. Most file managers have better facilities to find and manage files, so you can paste the path into it or use a command like `rox -s (paste)` to get the file you want. It also works if you drag and drop a folder in it to switch to the folder. Improving the filepicker to make it work for everyone is a fool's errand. Much better off making it integrate with filemanagers adequately. As for the systemd dependency, I think this is firmly a case where the only way to change their minds is to make the changes yourself, maintain a rebase fork[1] for several years, and show that the demand is there and the complexity is worth it. Considering the major Linux distributions default to systemd and it has a variety of features not included in traditional init, I can understand why they wouldn't want to do it unless it was proven to be valuable in advance. [1] Do not give it a different name: it's just "the gnome fork that takes full advantage of systemd when it's present but does not require it". Do not increase or decrease its scope: no fixing filepickers or adding traditional menubars. Either of those will cause Gnome to say "It's a different product" rather than "it proves the demand for non-systemd" amongst gnome users.