Comment by ginko
4 years ago
>You'd need some way to inform the window manager that "windows from this process should be considered modals over this window of mine"
Why though? Am I the only one that hates modal windows? Why does the parent window have to be blocked by the dialog window? Can't it be like the color picker dialog in GIMP?
There are/were Linux window managers or desktop environments where the file picker was not held if focus above the main window. Or at least they can be configured that way. I know because I've done it.
It turns out, that when that happens, the user can accidentally focus the main window while the file picker is up, and then the file picker gets hidden underneath it. As a fun bonus, the application now _probably_ appears to be frozen/crashed because it's waiting for input from the file picker that the user can no longer see.
It's just a bad idea, man. For most people anyway.
Then, if the user interacts with the main window, just close the file chooser and don't freeze the application.
Or set the right window properties including WM_TRANSIENT_FOR so that the window manager knows that the dialog should be displayed above the window.
As much as I hate modals they are usually a product of single threaded or poor event loop design.
What happens if I hit File->Save, then while the file picker helper process is spawning I get an urgent instant message and tab away, and when I alt-tab back focus returns to GNOME and I close the tab because I forgot I didn't finish saving? Does the file picker go away? If I type a filename in the picker afterward and hit Save, does it save the file even though I closed the tab?
Just like webpages in browser can capture its closing and ask you if you really want to quit.
Same with your proposed workflow, when you try to close the tab, the file picker will pop up again (within the visible area of the tab, not on another monitor), tab stays opened.