This is a pet peeve of mine - why is it that in Linux it's idiomatic to start like 5 processes and pipe their outputs together to find a file containing a certain word from the shell, but something like a file chooser cannot be its own program?
That's happening! Gtk 3 and 4 include GtkFileChooserNative[1]. It works like a file dialog except the application doesn't know about its widgets. That means it can proxy another application.
So if you're running a Gtk app in a sandbox like Flatpak or Snap, Gtk will use the Xdg file chooser portal[2]. In GNOME, this is implemented by an application (in the host) which, itself, creates a GtkFileChooser. In the future, it could be a beefier application. One benefit of that taking a while to happen is, once the implementation gets fancier, there won't be too many weird mismatched applications.
(Also, I mention GNOME, but it's important to notice the file chooser portal is itself platform neutral; KDE apps use this, too, and the implementation depends on what desktop you are running. Yay, decoupling!).
Not everything uses GtkFileChooserNative, but pretty much any recent Gtk app that doesn't have weird requirements probably does. Off the top of my head, Firefox, Secrets, Bottles, GNOME Builder and GNOME Text Editor (although they still ask for access to all of the of the files for other reasons), … even Slack and VS Code! (Electron switched over recently).
[1] https://docs.gtk.org/gtk4/class.FileChooserNative.html
[2] https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.free...
That bundling file chooser with a GUI framework is a bad idea should be obvious since well, ... Java Swing?.
And a easy to use system interface for a file chooser isn't hard to make, could have been (preferable) a binary you call and communicate with pipes with or similar or could have been something else (e.g. shared object).
It's kinda sad that the various Linux communities where so focused on their GUI framework being the best that it didn't happen until it was technically needed (for sandboxing) ...
EDIT just to be clear 95+% of applications could use a cmd with Linux style arguments which once done emits the selected file(s) to stdout, but there are a minority of advanced use-cases which require a bit of two way communication. Through most of them are bad ideas anyway, so maybe that could have been ignored.
A lot of this stuff was "decided" back when we had serious memory constraints, and less technology to manage them. Switching processes was costly. Running the file chooser in the same application was an excellent compromise. A solution. (I remember an article about this problem in the context of early MacOS, along with drag & drop and the like. Will share if I find it).
In addition, having the file chooser in-process makes sense if you're trying to appease app developers, who think they want the ability to change everything. In particular, they'd really like to add a custom preview widget and some other gizmos to the file chooser. Photoshop puts all sorts of buttons in its Export dialog, for instance. And because Photoshop does it, a bunch of other applications think they should, too. And they still want to, even if they're using Gtk.
Saying "this is dumb, we need this dialog to be a simpler interface for [reasons] and if your app has a weird file dialog you'll have to deal with it" is a very decisive action, and it is not without friction. So I think the reason this took so long is partly an accident of history (the bad solution stuck because it was too late by the time we could afford the good solution), and partly just luck: things reached an inflection point where app developers actually get something (sandboxing and clever app containers) in exchange for the inconvenience.
But the time where the overhead mattered in any way is over since well over a decade.
Even when e.g. GTK3/QT5 was released the overhead of a out-of-process file chooser was more then irrelevant.
> makes sense if you're trying to appease app developers,
I have yet to see a single application which uses that for any reassemble thing which couldn't also work with a native file chooser (e.g. custom preview images) or can be handled well outside of the file chooser (but then I'm on Linux since quite a while, but this is about Linux in the end).
I have been hearing complains about non-native file chooser pretty much since I started using Linux 12? years ago. In difference to very few Linux programs customizing anything but filters in a file chooser.
So I don't buy that it's inconvenient for developers to any relevant degree (wrt. Linux) the very few application which insist on it still can roll their own file picker by using on of the "guaranteed to pop up" custom file picker libraries.
One the other hand having file picking as a system service would have lead to more consistent appearance, more convenience (consistent system interactions) and more accessibility (e.g. alternative system file picker specialized for blind people).
So you will have a hard time convincing me that it wasn't dump to not switch to native file picker around a decade ago when GTK3/QT5 came out, sure there where reasons, but there had been much more reasons in favor of it then against. It's just not a decision anyone ever did actively I guess, because not making a decision is easier then people across distros/GUI frameworks agreeing to making a decision.
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.
The freedesktop.org community really needs it's own Raymond Chen pass down all the accumulated arcane knowledge.
The comment links to the documentation, which says it explicitly...
And then, many other places in the documentation, e.g. https://docs.gtk.org/gtk4/method.Window.set_modal.html
> Modal windows prevent interaction with other windows in the same application. To keep modal dialogs on top of main application windows, use gtk_window_set_transient_for() to make the dialog transient for the parent; most window managers will then disallow lowering the dialog below the parent.
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
I find it particularly ironic or confusing because introspection seems so much less likely/more rarely to occur in anything technical; so why does it get that association? Because you're right, people do seem to use it as though it means 'highly technical inspection' or something.
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?
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.
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.
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.
I really wish we had another popular GUI toolkit that isn't Qt.
I'd much rather have one single toolkit standard so that everything can look and behave the same TBH.