Hacker News Reader

Comment by superkuh | Hacker News Reader

No. I actually went to GNOME's IRC network the other day to talk to them about gtkfilechooser's multiple problems. Yours, and then the lack of text input for typing or pasting file paths. https://gitlab.gnome.org/GNOME/gtk/-/issues/938 . They said they have no one assigned to gtkfilechooser bugs and none will be addressed.

I was able to download the debian source for a couple gtk applications (ie, gedit/pluma) and apply community sourced patches to them to get back the text/file path entry box. But there's no way I am going to be able to fix Gtk itself. And fixing every application on my system by compiling from source and making new debian packages, well, I might as well linux from scratch.

View on HN

I'm glad to hear putting hamburger menus in all the window title bars is prioritized over having a functioning UI.

This has been going on for a long time now and is to be expected. My real problem is that they completely remove existing functionality from UI without giving the users who relied on it any alternative.

Purely out of curiosity, what else is the Gtk team currently working on? People have been complaining about the file chooser for years.

I'd be willing to donate a good chunk of money just to support "basic UX" improvements to FOSS software and toolkits like Gtk.

Should we start a "Fix the Gtk file chooser" Gofundme?

It's more like decades, not years, by now. Seems worthwhile.

> Purely out of curiosity, what else is the Gtk team currently working on?

Probably redesigning the entire interface. "For your convenience".

which they also do for years.

The GTK team is like 3 people. GTK4 worked on improved cross-platform support, effecient gpu rendering, documentation, sandbox integration, etc.

UI designers are probably limited and there is just a lot of drama about the filechooser so it's easy to find other things to work on.

The patches already exist. In fact, PopOs! already has this feature merged.

I searched PopOs! repos and I couldn't find where they maintained their Gtk-3.0 patches or code. It didn't look to me like they altered Gtk-3.0 itself at all and likely just altered individual applications.

Fixing the GtkFileChooser is not the main problem, it is getting your patches merged. Someone from the Gtk team needs to review them and put their stamp of approval on them. But the Gtk team are RedHat employees and they prioritize whatever the company wants them to prioritize. And if the company doesn't want them to prioritize the GtkFileChooser, your patches will languish on their bug tracker. If you are lucky, you'll get a message two years after you uploaded them asking you to rebase them to HEAD because the code base has changed to much that your patches can't be merged without them being significantly reworked.

And now everybody should look for a text from 2003 written by jwz mentioning the "Cascade of Attention-Deficit Teenagers model" and slowly read it again, then think how much time passed since.

Shouldn't they be in their 30s by now?

Most Gnome developers, I suppose, are on RedHat payroll and are not teenage.

They are busy working on various things, this is certain, and these things are apparently more important for them. Like, well, GTK4.

I suppose most Red Hat customers are corporate, and when they ask for featureful Linux desktop, they likely mean playing nice with corporate systems. This is why Evince is such a good PDF viewer, compared to a lot of others; it can even fill in forms. This is why the file chooser without image preview is fine as is for corporate use, because I suppose that 0% of graphic designers choose a Linux machine in a corporate setting.

> Most Gnome developers, I suppose, are on RedHat payroll and are not teenage.

jwz was not talking about the age, he was talking about the issue of ignoring bugs to the point where they reach decades old, and often even then persist and go unfixed. Some bugs live multiple decades, across three different issue trackers, having to be reopened each time.

The fun fact is that he wrote this in 2003, about the GNOME developers. Not much has changed in 20 years, it seems.

https://www.jwz.org/doc/cadt.html

This article has so little substance that I wish people would stop re-posting it. It adds nothing to the discussion. Like yeah, there are bug reports that haven't been addressed. Developers come and go and sometimes have to leave before they get to work out all the bugs in their feature(s). It happens. Every big open source project is like that. The bug tracker is open so that anyone can submit bug reports. The downside is that it tends to fill up with unsolicited bug reports that don't get responses. The upside is that anyone in or outside the project can volunteer to fix any of those bugs. I don't see JWZ stepping up to triage random bugs in GNOME, probably because he knows it's a thankless job with no pay that he wouldn't enjoy.

The idea of "unsolicited bug reports" is lovely.

Exactly, what about unsolicited bugs?

> I don't see JWZ stepping up to triage random bugs in GNOME, probably because he knows it's a thankless job with no pay that he wouldn't enjoy.

Thing about it is, it's the responsibility of the GNOME project. It's the responsibility of the developers that sign up to it. Each time GNOME has been improved, old problems still persist. It says something about a project and the integrity of the developers when they claim to increase usability and yet do not bother with longstanding problems.

The root of the problem is a certain mindset to development. One that is numerous and yet flawed.

"Move fast, break things! No time to fix them we have other concerns like- checks notes- revising every system menu to look slightly different. Hell yeah!! Wooh!"

the main text entry ("Name", the one that starts out focused) lets you type/paste paths.

Not in GTk 3.24.5.

It loses focus once you switch directories. Restoring focus to the default state involves selecting the filename, but not the extension.

Reply on news.ycombinator.com