Comment by jordemort
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" - probably something that's in the realm of the possible to hack together?
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" - probably something that's in the realm of the possible to hack together?
>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.
1 reply →
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.
For X11 there was no need to "hack" that - Window IDs are global so the file chooser just needs to be passed the value to set for its WM_TRANSIENT_FOR property.
Wayland might be more difficult since it likes to isolate processes more but considering this should have been common before Wayland was designed it could and should have influenced that design.
"Here are my screen coordinates, I'm going modal while you're running" seems like a perfectly adequate answer to that.
How do message box (alert) popups work?
in GTK when you instantiate the window you pass what is called the "transient for" property (https://docs.gtk.org/gtk4/method.NativeDialog.set_transient_...). That informs the dialog what it belongs to. If you were to re-engineer this to make the file picker its own process, then you would have to fundamentally change the way it functions, sadly.
Edit: And I think Wayland would make this impossible? Someone correct me if I'm wrong here, but don't you lose basically all inter-window introspection with it? There may be some negotiation process, but I don't know how you would go about accessing an entirely separate application's context under that pipeline.
I bet this info isnt written down explicitly except in this comment.
The freedesktop.org community really needs it's own Raymond Chen pass down all the accumulated arcane knowledge.
1 reply →
> inter-window introspection
This oxymoron is a pet peeve of mine. If it's inter-window, then it's just inspection. Introspection is when something inspects itself, but people seem to think it just means inspecting anything technical.
Great post though, I just needed to get that off my chest
4 replies →