Drop the attach-modal-dialogs override in GNOME Shell
While modal dialogs being attach to their parent window works fine for message dialogs that require an answer from the user, it's sadly breaking apart when the dialog is a complex bit of machinery, like the file selection dialog.
In the early (2.x) days of GtkFileChooserDialog
, the window size would be small to begin with, with a file name entry and a directory, and could be expanded to navigate through folders, similar to the old macOS file selection dialog would work; the idea of attaching that dialog to the parent window (also inspired by macOS) would generally work well enough because the dialog was small and did not cover a lot of the parent application's content area.
These days, a GtkFileChooserDialog
is the equivalent of a small application itself, as it's been deemed necessary to add feature parity with a file manager to it. This, though, means you now get the equivalent of a Nautilus window stack on top of an application, and you cannot move it away without dismissing it completely, and starting from scratch.
There's the instinct of shoving even more information in the file selection dialog, and have applications pre-fill as much as possible into it, so that you don't have to switch back to the application window when you need to name the file, or change folder, or do anything else; this requires far too much collaboration from application developers, and the toolkit cannot divine things out of thin air to help developers and people using applications.
While we could, in theory, attach a new type hint to the file selection dialog, this would need negotiation with every other toolkit and window manager, down to the protocol level, as neither X11 nor Wayland have this kind of hint. Of course, this would also be repeated every time we come up with a dialog that is sufficiently complex as to shadow the parent application.
The main suggestion is to stop overriding the setting in GNOME Shell, and keep it to "false".
Alternatively, Mutter could check the size of the dialog and, if it's comparable to the size of the transient-for parent, it could avoid attaching it.
On the "fancy" side of things, we could make the dialog semi-transparent if the pointer crosses it, but still remains within the parent window; this would be kind of unexpected, and could mess up some of the accessibility stack.