Comment by superkuh
4 years ago
The biggest problem with GNOME right now is Gtk3 and gtkfilechooserwidget.c. It is so spaghetti and so many things rely on it that no one at GNOME is willing to work on it for fear of breaking something. And for the same reason they won't accept drive-by patches. It is, effectively, frozen broken, and has been for many years. This applies to any attempt to add thumbnails to the file chooser but there are far worse, actual bugs, beyond the lack of thumbnails.
As of right now if you File->Open in any program using modern Gtk3 and try to paste a file path in you'll get an error instead of pasting your filepath in a text field to open, "The folder contents could not be displayed\nOperation not supported" http://erewhon.superkuh.com/gtkfilechooserwidget-paste-fail....
It's unfixable behavior because the GNOME devs stopped respecting their own gsettings, org.gtk.Settings.FileChooser location-mode, to FORCE the path-bar experience on everyone. Because no one needs to type file paths, apparently. So why bother respecting the settings for path-bar or filename-entry? Their demographic doesn't care. Unfortunately gtk3 is used by far more than GNOME's demographic.
They have fixed this bug in gtk4, for all the good that does.
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?
> … 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...
What I don't understand is why it took so long.
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.
2 replies →
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?
6 replies →
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?
8 replies →
GNOME often rejects the ideas from the rest of the ecosystem.
It's a matter of human resources, gtk3 is an extremely small team compared to its influence.
Haven't the GTK developers basically admitted that GTK exists to serve the needs of GNOME, and if anyone else gets good use out of it, that's accidental and unsupported?
I really wish we had another popular GUI toolkit that isn't Qt.
1 reply →
>> It's unfixable behavior because the GNOME devs stopped respecting their own gsettings, org.gtk.Settings.FileChooser location-mode, to FORCE the path-bar experience on everyone. Because no one needs to type file paths, apparently. So why bother respecting the settings for path-bar or filename-entry?
Control + L will turn the path bar into a simple string w/ autocomplete. Am I missing something here or are you talking about pasting a path into the filename portion of the dialog?
Hiding important features behind arbitrary keyboard shortcuts is definitely on my list of things I hate about modern desktop environments. (Not to mention, extremely unfriendly to accessibility.)
i installed a new debian box for work and i forgot to choose xfce4 so went with the default. gnome 3. i tried. i tried so hard to get used to it. for 2 horrible months i tried.
i only need a terminal, emacs, browser, thunderbird, the occasional screenshot and it was still horrific.
to be clear it was only the usability that was a nightmare. i experienced no bugs. it's solid. but wow it is unusable.
please, please, please someone at gnome headquarters ... can you make it usable? look at win10, win11, macos, kde, chromeos they all work fine. can't you do something like that? i believe you have the best software stack out there, and you're throwing it away with that frightful design.
this is tragic.
This is purely my impression and not something I could prove, but it feels like Gnome wanted to have an out-of-the-box Mac-like experience, while not really understanding while people like using Macs. "You don't have a million configuration options on a Mac, so neither should we!" doesn't account for Apple having whole departments working on UI things, choosing sane defaults, etc. People don't like macOS because it doesn't give them options, but because it tried to make good decisions and patterns so that they won't need to tweak everything.
I know lots of people don't like Macs because they're not super tweakable, and that's fine. It's still my impression that Gnome is aiming for that target, while not quite understanding why a lot of people do like Macs.
100% my impression as well.
and you're right. macos is fine from a usability point of view. everything in gnome UI feels like they started strong, stayed strong, and then gave up half way ... (so many examples there's no point listing them anymore) and yeah put the clock in the middle of the bar while we're at it too.
and yet, you feel the potential no? no bugs whatsoever for me.
:/
back to xfce4. clunky, but consistent. some bugs. it's ok.
1 reply →
No idea what problems you encountered, but I find Gnome to be a joy to use. It was such a relief after years on Windows. Gnome Boxes is such a smooth experience compared to VirtualBox. Maximizing content area by putting UI elements in the title bar is also something I appreciate.
The problem is that nobody puts the right elements in the titlebar. It has just become a place where they improperly put "SAVE" for dialog boxes, when there was plenty of room in the dialog to begin with. It's kind of just become a dumping ground to put the shit that everybody doesn't want to deal with. It's like the hamburger menu, it might have some benefits, but now everybody just throws all the shit in there that they don't wanna deal with. Why would you fill out a form going down the list, and then have your save button all the way at the top of the window? Why bother trying to make a good, intuitive UI, when you can just make a giant heap of shit and put all your leftover stuff there? And then to top it off, now I can't move the fucking window, because the titlebar is full of trash.
The biggest problem with GNOME is that the organization needs to get their shit together. Their priorities and design choices are awkward at best so I must say they don't care for their users at all.
GNOME's design choices are either extremely good or extremely bad. I like the general workflow, but the panel looks like some crummy i3 config. You could almost get rid of GNOME's panel altogether, placing the network icon etc on the "Applications" view. You can't even switch Audio or Bluetooth devices using the panel. It's dead real estate.
this is seriously a mystery to me. how do people use gnome? how can you be productive with it? i tried so hard: https://news.ycombinator.com/item?id=31782882
I use GNOME and honestly like it despite the many flaws. May be some sort of Stockholm syndrome, IDK. As I see I spent most of my time on the CLI or on the browser so the DE in itself doesn't matter that much and GNOME advantage is that I don't have to waste time troubleshooting and customizing it (not even possible sometimes) so I can focus on the things that matter. If you compare DEs pages on Arch Wiki, GNOME by far has the smaller 'Troubleshooting' section. Also when you use something for a long time you know how to workaround it's limitations and fix things while.
How come does every distro default to it, make it incredibly hard to opt-out, and then decide it's the best one available because it has more than double the installed base of the next option?
I simply do not understand people.
I use GNOME only because my favorite OS right now is Pop OS and it's what they ship by default. Otherwise, I'd still probably be laboring to get KDE, XFCE, or MATE to be a satisfactory experience.
The only thing that makes GNOME bearable for me are a handful of extensions and post-install tweaks. Specifically Dash-to-Panel and ArcMenu.
The biggest thing that still annoys me is the GNOME folks have this fetish about stuffing as many widgets as they can into the titlebars of windows.
It's like using MacOS- there is a set of limited utility it provides, and anything else must be achieved externally, ie- with another DE, WM, or in terminal.
For very basic desktop usage, GNOME 3 does about 65% of what I need. Because it's Linux, I can have TTYs that run KDE, i3, or more customized shells that accomplish the rest.
Not doing this would be an exercise in learned helplessness, which is exactly what I chose Linux to get away from.
I use GNOME technically, but in earnest I use whatever Pop!_OS decides to go with. It’s been fine transitioning off LXDE and macOS for me. That said, I don’t feel like a Linux power user or anything.
The file chooser has been broken since at least gnome 2, and was antiquated in the gnome 1 days. I don't believe it will work in gnome 4.
I understand how things get this way, but it is a super easy problem to fix:
1. spin up a new file picker: GTKFilePicker.c
2. add a deprecation warning to gtkfilechooserwidget.c
3. wait 20 years, then git rm gtkfilechooserwidget.c
>The biggest problem with GNOME right now is Gtk3 and gtkfilechooserwidget.c. It is so spaghetti and so many things rely on it that no one at GNOME is willing to work on it for fear of breaking something.
I wonder, why can't they introduce something like gtkfilechooserwidget2.c leaving the original widget intact?
The big guest Jon for me is, in 2022, why write UI code in C? (I say this as one who contributed to GNOME a little (all icons) back in like ’98–’02 and who writes high-performance C++ professionally.)
A lot of work, maybe? Also, bug-to-bug compatibility?
It could be a cleaned up version of the widget minus the warts. Applications wouldn't need bug-to-bug compatibility if it was a conscious choice to upgrade to a new widget.
You may know this, but if you type / in the file chooser window, it replaces the path buttons with a text bar that you can type or paste into. I discovered that by accident, probably a couple years after the text bar vanished...
or ~ if you want to navigate $HOME
Try typing the name of a folder that will be found by the integrated tracker search into a gnome file chooser that’s trying to save a file. Then double-click that folder. The results are poor, to say the least.
My favourite idiocy is that gnome-terminal will offset the items in the right click menu and display hex and and octet translation of a number you happen to have highlighted... for reasons.
When someone posted this as a bug because of the obvious unintended idiocies with this a being a default immutable behavior, the maintainer essentially told him to f off and go build his own version.
https://bugzilla.redhat.com/show_bug.cgi?id=1644986
Made another MacOS covert with that exchange, I'm sure.
I don't get your last comment? Everything is going to move into gtk4 or move to other toolkits as gtk3 gets obsoleted, it's the way of the world.
Suspect one of the impetuses behind such stagnation is that in reality not that many Linux users use GUIs to do file stuff as so many of us live in the command line.
>> Suspect one of the impetuses behind such stagnation is that in reality not that many Linux users use GUIs to do file stuff as so many of us live in the command line.
GTK is a GUI toolkit. It is literally made for building GUI applications. The Gnome developers are building a graphical DE. Your reasoning doesn't seem to sensible to me.
It makes sense to me. Developers work on a project (and most definitely open source developers) because they feel some friction with a system. Maybe it’s a task they want to automate, or a bug in some software they need to use. But either way — there must be some pain point that is causing them friction. This is what causes some program/feature to be written or updated or fixed.
If those developers have a perfectly good work around, then there is no pain point for them. It doesn’t matter if it is a pain point for their GUI-exclusive users. If they don’t feel the pain, it won’t be prioritized.[*]
This isn’t a criticism of Gnome per se, but rather a reality of time management. There is only so much time to go around, which means features and bugs get triaged. If none of the developers feel like this is enough of a pain to get into the quagmire that is the GtkFileChooser (?) widget, then it will not be touched.
[*] That is, of course unless they are being paid to do the work. If you are volunteering, then you get to choose what work to do. If you’re getting paid, the suddenly not working on the file chooser could become a pain point for the developer (as they might not get paid). Which is the major advantage commercial OSes have over their open source competition.
7 replies →
the impetuses are shrouded in mystery, what with the metaphorical GTK+, and the whatever it is the gnomers are doing over there. a graphical DE it is not, but it has "graphics".
sigh
it could be so awesome if a non-schizo designer got involved. it's frustrating really. so much potential, such thick window bars.
it is so stupid.
2 replies →
My point is that due to lack of users it doesn't get better. I've modified gnome in the past to meet my requirements
Gtk3 filechooser worked fine until 2014. Distros with gtk3 released before this have a gtk3 lib that handles pasting file paths in the file chooser and the gsettings still work. My last desktop with functional Gtk3 is Ubuntu 14.04 on Extended Service Mantainance (ESM) support. But it'll age out of support fairly soon.