💾 Archived View for gemini.hitchhiker-linux.org › gemlog › the_file_chooser_button.gmi captured on 2024-02-05 at 09:47:09. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-06-14)
-=-=-=-=-=-=-
I am a great admirer of Gtk+ and have always felt that it is simply the best and most comprehensive toolkit available in the open source ecosystem. One might argue that it's the best toolkit period. That said, there have been a few things over the years that have left me scratching my head, and one of them was that when Gtk4 was released it saw the deprecation of the GtkFileChooserButton. According the the instructions for porting applications from Gtk3 to Gtk4:
The GtkFileChooserButton widget was removed, due to its shortcomings in the user interaction. You can replace it with a simple GtkButton that shows a GtkFileChooserNative dialog when clicked; once the file selection has completed, you can update the label of the GtkButton with the selected file.
Note that we still have access to GtkFileChooserWidget and GtkFileChooserDialog. I'm not in the know about what "shortcomings in the user interaction" is referring to, but let me point out that we still have the following:
So yeah, this is majorly mixed messaging. One can assume that all of these widgets, having the same mode of interaction as the removed widget in question, suffer the same shortcomings. However this isn't really my only issue with the above explanation. Let's say that someone followed the above advice and created their own file chooser button, which displayed the full path to the chosen file. Hypothetically, the button's purpose is to choose a file for a background. Is it actually practical, and good interface design, to display the full path to, say, /usr/share/backgrounds/mate/nature/YellowFlower.jpg, or is it better practice to just display the file name, YellowFlower.jpg? For one thing, showing the full path gives too much information and clutters things up. For another thing, that button now defines the minimum width of the window because it's just ridiculously long. So really what is wanted is to just display the file name and store the path as a property. Interesting enough, the old deleted widget did just that. It's still not a difficult thing to code up yourself, but it's basically a custom widget at this point which means subclassing a GtkButton to add behavior.
I first ran into this when writing Eva's preferences dialog. One of Eva's setting is whether to ask for a location every time a download is requested, or whether to use a specific directory. For the latter case, the most appropriate widget is the file chooser button. So I rolled my own, in a fairly janky way. Fast forward to now, and I'm working on OxTerm's preference window. OxTerm will give you the choice between using a solid color, gradient, or image for the background (just like Zterm). If using an image background, then we need to pick a file, and the most appropriate widget is once again a file chooser button. Here wee go again. So putting this into numbers (and realizing that this is a really small sample size) I have three programs using Gtk4 (Gfret, Eva and OxTerm) and two of them need this deleted widget. I would submit that a huge number of developers are going to stumble over this and I call bullshit on the validity of the project's reasoning for deleting it.
This particular widget seems to be most often used in a settings dialog. Current thinking in the Gnome project is that any additional settings are harmful and to be avoided. I understand the idea at work here, that each additional setting is a new code path that must be maintained. I agree that we've seen projects go way too far down this path in the past, and that there are times when the burden will drag down the overall quality of the porject. What I don't agree with is the extremes to which the Gnome project take this, to the point of now removing widgets from the toolkit which are primarily useful in terms of a settings dialog.
I am already annoyed by running into this for a second time, and want something ready to go for every time in the future that I run into this same issue. So I took the liberty of creating a Rust crate for it which includes a ready to go FileChooserButton. The widget subclasses a GtkButton and stores an internal reference to a GtkFileChooserDialog. It additionally stores a reference to an Option<gio::File> representing the chosen file, and wraps the vast majority of the GtkFileChooser api as methods on the FileChooserButton widget itself. For accessing behavior of the associated dialog, one can access the internal reference to it with the FileChooserButton::dialog() method. It should be a good drop in replacement for 95% of the times one might require this sort of widget, assuming one is writing an application in Rust using Gtk4. It represents only an hour or two, but I'm happy knowing that it's effort I won't have to duplicate in the future. For now it's only available in the git repo on Codeberg but I'll probably publish it on crates.io at some point once I add some documentation. It should be easy enough to use and may very well be useful for others as well.
https://codeberg.org/jeang3nie/gtk4-file-chooser-button
All content for this site is licensed as CC BY-SA.
© 2022 by JeanG3nie