1. 48

  2. 24

    So I read through the issue, and excluding all the noise the essential timeline on this is:

    March 2011: someone posts patch, some usual back-and-forth review/feedback on this until June 2011:

    The only remaining problem, as far as I can tell, is that the “Type name of new folder” text persists below the actual editable entry when you are editing… I don’t know what’s causing that, yet. Could you take a look, please? If you don’t have time to work on this anymore, just tell me and I’ll finish it.

    Unfortunately I have no clue how to fix this.

    And then nothing until Oct 2012, and by then some things changed in GTK and needed more fixes. It looks like the original patch author had lost interest at this point.

    In March 2014 after some more complains, and maintainer commented:

    If you want to make this feature happen, then I humbly suggest you write a patch for it, instead of leaving comments on Bugzilla. all we can do is help you (or whoever else wants to tackle this) in writing the patch, getting it reviewed, and accepted.

    Well … someone did, but okay.

    March 2015, someone writes a new patch. Some very superficial feedback a few weeks later from “mr please write a patch” (“I haven’t looked at your code”), author responds some more, and then … nothing. Crickets.

    April 2017: someone outlines what they perceive to be some problems to get this implemented, but this isn’t a response to the actual patches as far as I can see (which by now are 6 and 2 years old), and previous comments indicated it mostly worked okay, so I don’t know…

    Oct 2017: New patch! Some feedback follows and someone continues to develop it until Jan 2018. It seems acceptable and to work well, not entirely sure why work stopped.

    May 2019: some people asked what happened to the previous patch from Oct 2017 posted to Bugzilla, and what happened to it. The extremely helpful feedback on this is “Until we get a merge request that we can review, “random patches on github” are not something we’re going to look at, sorry.”

    Issue is locked a few weeks after this.

    I’m not entirely sure what to make of all of this; there are some vague concerns about performance, but nothing too concrete. I don’t really see anything really concrete preventing this from being implemented other than “no one wrote a patch” except …. that three people did.

    It’s no surprise that people have given up and started maintaining out-of-tree patches for this.

    And people posting patches on the then-appropriate channels that were then ignored for years until you all moved to a different platform are not “random patches on GitHub”. Look, we all get that this kind of stuff is volunteer work, but maintainers also need to understand that people writing patches are doing the same volunteer work as you are. Smacking those patches down over such a triviality isn’t not exactly great. And explicitly soliciting for patches and then ignoring them is even less great.

    I don’t know what drives this attitude, but my own suspicion is that the (many) people complaining “plz fix this!!! its ridiculous its not in GTK!!!!!!11” probably aren’t helping. I don’t know about other people, but when people start being pushing and demanding things my first (emotional) response tends to be a “fuck off” and I’m actually less likely to work on it. But even then: you take a deep breath, look at the actual issue at hand, and take the appropriate action. So idk 🤷

    At any rate, if I want to find an image from my ~/pics then I start geeqie, find the image in the thumbnail there, remember or copy the filename, and then paste that in Firefox (I don’t use gnome, but Firefox uses the same file selection dialog) and then, because the preview is almost comically tiny, I need to press my face against the screen to make sure I actually selected the right image.

    Is this the biggest issue in my life? Hardly. But it all seems so … unnecessary.

    gnome.org claims it’s “An easy and elegant way to use your computer, GNOME is designed to put you in control and get things done.”

    1. 13

      It’s little things like this that add up.

      Indeed. It’s for this reason I’ve given up on Linux as a desktop OS and only use via SSH these days.

      1. 4

        There was at least one effort to get this fixed, which lives in the gtk fork here: https://github.com/Dudemanguy/gtk

        But apparently the code is not good enough to be merged (because it’s using potentially slow APIs?). There’s also a few more links to patches in the gitlab thread https://gitlab.gnome.org/GNOME/gtk/-/issues/233

        This comment is also interesting: https://gitlab.gnome.org/GNOME/gtk/-/issues/233#note_106555

        GtkFileChooserNative is also mentioned, which should get you a native file open dialog on macos and windows (not sure about a Qt one on KDE, I think there’s an env var that can be set).

        There was also a branch with work on this on the GNOME gitlab but it seems stalled: https://gitlab.gnome.org/federico/gtk/-/tree/filechooser-icon-view-3-22

        1. 2

          One thing I’m sure about after reading that is this author is the person who cares most about this issue in the world.

          1. 4

            I’m not so sure: back when I used to read /g/, an image board, it was one of the main arguments people raised against “Linux” (serious or not). But it makes sense, that if you want to use and pick images all the time, that it will annoy you more. The best workaround I know of is to use the regular file manager to find a file, and then drag-n-drop it into the picker.

            1. 1

              more likely the author is able to identify what exactly feels off, rather than just saying “this desktop is crap” and going to something else.

            2. 1

              What’s the point of doing a whole upgrade of the GTK toolkit while ignoring this problem?

              Looks like there were other priorities: https://gitlab.gnome.org/GNOME/gtk/-/milestones/1?