[HN Gopher] GNOME has no thumbnails in the file picker (and my t...
___________________________________________________________________
 
GNOME has no thumbnails in the file picker (and my toilets are
blocked)
 
Author : jfax
Score  : 275 points
Date   : 2021-01-10 21:04 UTC (1 hours ago)
 
web link (jayfax.neocities.org)
w3m dump (jayfax.neocities.org)
 
| skynet-9000 wrote:
| How about when you try to save a file, so you choose File Save
| As, change the directory, and then try to start typing the
| filename and it starts _searching_ (recursively!) instead of
| letting you type your new filename? Even better (not), then it
| lands on the first matching search item and makes the filename
| _that_ filename?
 
  | apricot wrote:
  | That insane bug was reported many times, and every time the
  | developers reply that they won't fix it, it's our workflow
  | that's broken.
  | 
  | Are we sure GNOME developers aren't some kind of agents
  | provocateurs working against free software?
 
| ncmncm wrote:
| The contempt for user experience displayed at Gnome, over such a
| long period, is breathtaking, _in its way_ , but Gnome are
| certainly far from alone. Apple presents the same experience, to
| me, except involving different details. Windows, too. KDE, too.
| Maybe one or other get icon-view in file pickers right, but there
| is a lot else to be got right, and they don't. More importantly,
| they neither want to get it right, nor want to enable you to get
| it right.
| 
| The commonality is not the details, which differ, but the
| attitude. "This is _our_ thing, not _your_ thing, so we will do
| what _we_ like, not what _you_ like. " This is most evident in
| cases when a shiny new release, with hundreds of new singing,
| dancing penguins, breaks a thing that used to work.
| 
| "The old release was better." "But look, dancing penguins!"
| "Dancing penguins do nothing for me." "But look, dancing
| penguins!" "I want a way to switch back." "NO. Dancing Penguins!"
| 
| Apple's great achievement is getting their customers to believe
| that they always and only ever cared about the dancing penguins,
| and to forget instantly about each thing that used to work once
| it is gone. Gnome aspires to that, but lacks Apple's reality
| distortion field, so must make do with contempt.
 
| 29athrowaway wrote:
| The reason people use Windows is:
| 
| - Because it comes preinstalled in their computers.
| 
| - Because that is what schools and workplaces use.
| 
| - Because MS Office is the de-facto office suite (although now
| you have Google Docs, LibreOffice, FreeOffice, etc)
| 
| - Because most games are released for Windows.
| 
| All these reasons are pretty sad.
 
| antonios wrote:
| Indeed. Unbelievable omission for a project that touts simplicity
| and usability above else.
 
| sampo wrote:
| The Xfce file manager, Thunar, has thumbnails. For casual use at
| least, it is very similar to the Gnome file manager.
 
  | incanus77 wrote:
  | Sounds like a good alternate toilet.
 
  | colonwqbang wrote:
  | Thunar is great, however it does no good here. Your various
  | programs like GIMP will always use the Gnome/GTK file picker
  | because that's what they've been programmed to do. Or, if not
  | based on GTK they will use whatever other file picker their
  | toolkit provided.
 
    | shrimp_emoji wrote:
    | >Thunar is great
    | 
    | Thunar is to Dolphin what a slingshot is to an M16. I never
    | understood how people settle for such barebones file managers
    | (i.e., less featureful than Windows Explorer).
 
  | puzzlingcaptcha wrote:
  | Interestingly, Thunar has had a similar pet peeve: it could not
  | remember per-directory view settings (e.g. sorting order). This
  | was finally fixed a couple months ago, 13 years after the
  | original bug was filed (#3521).
 
    | colonwqbang wrote:
    | I started writing a comment about this but then I saw that it
    | finally got fixed!
    | 
    | Not a day too soon, it makes thunar a lot easier to recommend
    | to others. And saves me some time when looking for things in
    | my downloads directory!
 
  | opencl wrote:
  | The post isn't actually about GNOME's file manager (which does
  | have thumbnails), it's about the GTK file picker which is the
  | same in any DE.
 
    | lmz wrote:
    | And without reading the bug, the issue with adding thumbnail
    | support to that one is probably because thumbnails need to be
    | cached to be fast, and it would be odd for a filepicker to be
    | creating its own cache files (since it can't make any
    | assumptions about the system it runs on).
 
      | ubercow13 wrote:
      | It's not that. Firstly there is a standard for where to
      | cache thumbnails at least on Linux, and secondly the file
      | picker _already_ generates (or at least displays)
      | thumbnails. It 's shown in the article. It's just that GTK
      | has no suitable widget for showing them properly.
 
  | [deleted]
 
| teekert wrote:
| Omg, this is insane, I now realize I automatically memorize the
| first 3 and last 3 parts of filenames I need in the picker... For
| screenshots I read the date very carefully and fear the day I
| upload a wrong one. I was going to the toilet with a plunger, not
| even realizing it.
| 
| Btw, if you work on MacOS (which has been a while for me now),
| you get very used to hitting space everywhere to get previews.
| What a feature!
 
  | swebs wrote:
  | I just don't even use the picker. Most sites support just
  | dragging the image from Nautilus.
 
  | vetinari wrote:
  | FYI, Gnome Files has exactly the same preview via space as
  | Finder.
 
  | another_kel wrote:
  | There's also QuickLook on Windows 10 store which does the same
  | thing. https://www.microsoft.com/store/productId/9NV4BS3L1H4S
 
  | city41 wrote:
  | I don't understand the wrong screenshot fear. Can't you confirm
  | it's the right one once you select it and see the preview to
  | the right?
 
  | therealmarv wrote:
  | There is a solution called GNOME Sushi which enabled that also
  | in GNOME. Also a Windows solution is existing (forgot the name)
 
| whatever1 wrote:
| Linux was always a Terminal-first OS. The UI efforts never came
| close to the depth that MacOS and Windows have.
| 
| Take for example the scaling issue. It has been now almost half a
| decade with 4k Displays, and Linux still does not know how to
| deal with it other than 100% or 200%. Currently Linux is unusable
| for anyone with a modern display.
| 
| I appreciate the work that all the contributors put -for free- in
| projects like gnome and kde, but unfortunatelly, it is not
| enough. You need a Giant with financial incentives to drive this,
| like Google did with Android.
 
  | priomsrb wrote:
  | Not sure what you mean. I use a 3440x1440 display with 118%
  | global scaling using KDE.
 
| drivingmenuts wrote:
| > First of all, how do developers so casually ignore this issue?
| Second of all, how do users so casually ignore this issue?
| 
| Because it's not important enough to them to force a fix. Hard to
| believe, in this day and age, but some developers have other
| priorities, especially when working with free software.
| 
| I question if this is actually a bug. It seems to be working as
| intended, just not the way the author wants. Seems like the
| quickest solution would be for the author to either take on the
| job themself, or absent the time or expertise, pay someone else
| to do it.
 
| enriquto wrote:
| In this time and age, do we really need "desktops"? If you only
| need a full-screen terminal and a full-screen browser (as is the
| case for many people), the whole desktop thing is unnecessary
| clutter.
 
  | AnIdiotOnTheNet wrote:
  | Someone is living in one hell of a computing bubble.
 
  | etaioinshrdlu wrote:
  | Terminals are probably never again going to be the primary
  | computing interface for most people.
 
    | enriquto wrote:
    | > Terminals are probably never again going to be the primary
    | computing interface for most people.
    | 
    | So what? Neither are desktops! The question is that the total
    | number of terminal users is certainly increasing year after
    | year.
 
    | mgreenly wrote:
    | Without question I think that's true, but they certainly will
    | be the primary interface of some people forever.
 
  | branon wrote:
  | A desktop for most people is a crutch (plunger) for their
  | disorganized computer (clogged toilet). I think the suggestion
  | that desktops aren't necessary is a good one.
  | 
  | Several years ago, I started turning desktop icons off (both
  | GNOME and Windows make this easy) and it really helped my
  | organization, as I was then forced to competently organize
  | files into Downloads, Documents, Pictures, Videos directories
  | instead of vomiting everything onto the desktop. Simply
  | _knowing_ where files are located is faster than scanning a
  | cluttered desktop.
  | 
  | As a bonus I don't ever have to worry about the positions of my
  | desktop icons changing.
  | 
  | File picker definitely needs thumbnails though.
 
  | guerrilla wrote:
  | Yes, I want to be able to look at more than one thing at a
  | time.
 
    | enriquto wrote:
    | Then you need a window manager, not a desktop.
 
      | santoshalper wrote:
      | You mean like the literal desktop, the icons and whatnot?
      | 
      | What does that even have to do with this article, which is
      | about a file picker?
 
| jancsika wrote:
| Somebody in Gnome did an awesome thing and I want to know who it
| was:
| 
| If I open my laptop after being logged in, I can just start
| typing my password and the login manager does the right thing:
| "Hey, he's probably typing a password. Let's throw it into the
| password widget and see what happens..."
| 
| I'm on an XPS running Ubuntu 20.04.
| 
| Who implemented that feature? It's a great ergonomic feature and
| improves the UX of logging in so much.
 
  | uncledave wrote:
  | The scary thing is we've moved on from there on other platforms
  | because those problems were solved forever ago.
  | 
  | I sit at my Mac desktop, press _any_ key on my keyboard to wake
  | the machine or tap the touchpad and I'm logged in.
  | 
  | Being impressed with the very small changes is a symptom that
  | there are lots of small problems. The most important change for
  | me is I rarely if ever have to enter a password now while at
  | the same time, no random joe can sit at my computer and use it.
 
| albertzeyer wrote:
| You will find lots of such examples of a feature which you
| personally find very important and wonder why such a simple thing
| is not supported yet. I guess everyone has such examples. And you
| will also find such examples for MacOSX or Windows.
| 
| For me personally, I wonder why mouse wheel/scroll acceleration
| is still not implemented. I implemented it a while ago for Xorg,
| which is outdated now, and also the maintainer was not happy with
| my approach. It's now a long outstanding proposal for libinput,
| https://gitlab.freedesktop.org/libinput/libinput/-/issues/7 /
| https://gitlab.freedesktop.org/xorg/xserver/-/issues/405
| (original bug report from 2010:
| https://bugs.freedesktop.org/show_bug.cgi?id=29905).
| 
| Anyway, I guess there are actually not too much people caring
| about this feature. And the intersection of those who do and
| those who have enough free time and knowledge to implement this
| is just empty.
| 
| Btw, I don't quite understand the comment about KDE. It sounds
| like the the author claims that KDE lacks other relevant
| features. But comparing Gnome vs KDE, it is quite clear that KDE
| has much more features. This is never a complaint I heard about
| KDE.
 
  | andrewmackrodt wrote:
  | I love Linux desktop but miss these creature comforts too. For
  | me, my biggest input issue is the lack of customisation around
  | trackpad deadzones, i.e. the 15% or so deadzone on the left and
  | right of the trackpad. My trackpad is exactly in the center of
  | my laptop but my palm is usually offset slightly to the left.
  | This means my first interaction with the trackpad often happens
  | in this deadzone area on the left-hand side of the trackpad, so
  | no input gets registered until I lift my finger and "enter" it
  | more towards the center.
  | 
  | There are a huge variety of laptops with different size
  | trackpads, different positions, varying levels of palm
  | rejection etc but there's zero customisability around this
  | seemingly simple behaviour.
  | 
  | My Windows dualboot has no such issue and macOS of course
  | (using a MacBook) works fantastically without this limitations.
 
  | tannhaeuser wrote:
  | While you're here and know a thing or two about libinput: it's
  | completely unusable for me, and the only reason I'm able to
  | work at all is that the old synaptics package (on which
  | libinput is based as a clean rewrite as I understand) still
  | works. The reason is that libinput doesn't support sensitivity;
  | I still remember the physical pain of hard-pressing the
  | touchpad when my current notebook was new, and in particular
  | the moment when I looked at the notebook and just stopped doing
  | anything at all on it in conditioned anticipation of a
  | frustrating experience. Also, kinetic scroll doesn't seem to
  | work, amplifying the issue.
  | 
  | I noticed Ubuntu have switched to KDE (or, alternatively, LXDE)
  | as DE for their "Studio" variant. I'm guessing that's mostly
  | because the minimal window decorations for resizing etc makes
  | gnome hard to use, and Studio is for large notebooks or
  | desktops anyway. I think the exercise of patience that was
  | resizing windows on gnome2 has slightly improved, but I'm still
  | speechless as to the loss of the global menu to be replaced by
  | ... a centered clock accompanied by a minimal dot that I found
  | out to display notifications after a while, and nothing else.
  | 
  | I mean I'm glad that F/OSS for desktops still exists at all,
  | but gnome3 is really just a big regression for no reason at
  | all, and I'm starting to get a bit concerned where gnome is
  | heading. It's not that we have a wealth of new desktop apps
  | anyway. Maybe Ubuntu is testing the waters to switch to KDE as
  | well.
 
  | alpaca128 wrote:
  | > it is quite clear that KDE has much more features.
  | 
  | My guess is that the author prefers Gnome because yes, it has
  | fewer features, but those feel more polished. KDE is powerful
  | but some less frequently used features felt more like
  | functional prototypes that were thrown somewhere into the nth
  | level of the system settings.
  | 
  | Then again the last time I tried it Gnome had a lot of issues
  | as well, so maybe I'm completely wrong nowadays.
 
  | swebs wrote:
  | At least enough people care that its become a meme in some tech
  | communities.
  | 
  | https://wiki.installgentoo.com/wiki/File_Picker_meme
 
    | jdright wrote:
    | Yes, and Gnome is in part responsible for a lot of "desktop"
    | issues with linux. Distros must switch to KDE by default to
    | help eliminate part of this stigma. KDE is so amazingly good
    | that there is no excuse to keep using Gnome.
 
  | phkahler wrote:
  | >> For me personally, I wonder why mouse wheel/scroll
  | acceleration is still not implemented.
  | 
  | This came up recently with SolveSpace. Two developers spent an
  | amazing amount of time getting scroll wheel zoom right.
  | Discussion here:
  | https://github.com/solvespace/solvespace/pull/825
  | 
  | Love these guys, they give a crap about usability. BTW next
  | release soon - after a bit more polish. Polish take time and
  | work, but do you really care about the software if you don't
  | spend _some_ time unclogging the toilet?
 
| sam_lowry_ wrote:
| Thumbnails are performance hogs
 
  | enneff wrote:
  | For who?
 
    | airstrike wrote:
    | All of us on a Pentium II 300MHz with 32MB RAM
 
      | sgt wrote:
      | Sweet. How many BogoMIPS ya got?
 
      | josefx wrote:
      | I don't think GNOME runs on those specs.
 
        | bananamerica wrote:
        | I think that was a joke, dude.
 
        | rleigh wrote:
        | GNOME 1.2 would have.
        | 
        | It wasn't until the arrival of Nautilus with 1.4 that the
        | requirements jumped and the performance tanked.
 
        | p_l wrote:
        | I think I had fast and reliable thumbnails at those
        | specs, but GNOME3 would lag too much (GNOME 1.4 did
        | because Nautilus was borked, but at least 1.4 didn't
        | patronize me as "dumb user, we the gnome/rhel devs know
        | better what you need")
 
  | josefx wrote:
  | And you can turn them off on any system that supports them when
  | that is an issue.
 
| CarVac wrote:
| My personal theory about why this isn't fixed is that in open-
| source software, if you halfass a UI implementation one time it
| keeps that halfass implementation more or less eternally because
| it's "good enough" for the person who learns to work around it.
| 
| For my photo editor Filmulator I resolved to _not add_ features
| that haven 't had the UI fully thought through. For a while it
| meant it was definitely subpar capability-wise, but now that it's
| approaching feature completeness it means that it's actually
| intuitive and streamlined to use.
 
| swebs wrote:
| Someone created a fix for this 3 years ago. The Gnome maintainers
| refuse to add it for whatever reason.
| 
| https://github.com/Dudemanguy/gtk
 
| therealmarv wrote:
| GNOME is in general terrible for everything with image related
| work (last tested on Ubuntu 20.04). In the past I thought finder
| on macOS is terrible (it's still the worst piece of macOS and I
| don't like it) but GNOME files aka Nautilus tops it for sure
| (also because of space wasting issues).
| 
| XFCE and KDE both do a better job than GNOME in this regard. And
| also Windows Explorer was and is much much better in this area.
 
  | sercand wrote:
  | Why do you don't like Finder? I couldn't think any issue with
  | it.
 
    | oneeyedpigeon wrote:
    | I could give you _so_ many, but I 'll kick off with just
    | three that spring to mind. i] Keyboard navigation is
    | _terrible_. ii] Tags cannot be applied to symlinks. iii] If
    | you 're looking at a tree view, with any number of folders
    | displaying, the only one you can create a new folder inside
    | is the very top-level folder.
 
    | therealmarv wrote:
    | My biggest complaint: Normal Copy and Paste does not work. My
    | mother is used to Copy and Paste and it would work in Linux
    | but not in macOS finder because of: think different
    | 
    | Also why are folders sometimes cluttered all over the place
    | and shorts cuts so weird?
    | 
    | Well I fixed it all with Forklift but I also grew up with
    | Norton Commander ;)
 
      | Klonoar wrote:
      | What about copy and paste doesn't work...? I use that
      | feature daily.
      | 
      | And for the clutter, you can configure Finder to be more
      | militant in how it displays/orders things.
      | 
      | The only gripe I have with Finder is needing to set up a
      | million QLPreview things to do better spacebar peeking.
      | Otherwise, it's fine - it "just works" and isn't fancy.
 
      | Teever wrote:
      | I actually filed a bug report with Apple in 2005 regarding
      | the inability to cut and paste files in Finder.
      | 
      | They actually responded a few years later and said that
      | this is the intended functionality.
      | 
      | Maddening.
 
        | Zarel wrote:
        | They do support copy and move, which I think is clearer
        | that the file doesn't get deleted if you don't "paste" it
        | (and safer than if it did).
        | 
        | It's probably annoying to learn a new paradigm, but you
        | could make the argument that it's worth it to learn
        | something that isn't lying to you.
 
      | spideymans wrote:
      | Can you elaborate? Copy and Paste works exactly as I'd
      | expect in Finder.
 
        | chrisseaton wrote:
        | I think they possibly mis-spoke and mean cut-and-paste,
        | which does appear to be intentionally permanently
        | disabled in Finder via the menu or shortcut. But you can
        | drag so it's not a huge issue to me. Copy-and-paste works
        | a-ok.
 
        | carlosrg wrote:
        | Cut-and-paste on Finder works perfectly fine too. It's
        | Cmd-C and then Option-Cmd-V on the destination instead of
        | Cmd-V.
        | 
        | Alternatively hold Option when opening the Edit menu.
 
        | chrisseaton wrote:
        | > Alternatively hold Option when opening the Edit menu.
        | 
        | This doesn't change the Edit menu for me. Does it work
        | for you today on latest macOS?
 
        | oneeyedpigeon wrote:
        | That's not cut-and-paste. That's copy and some weird
        | modified paste that, as far as I'm aware, doesn't exist
        | anywhere else. Why completely break the existing
        | convention?
 
        | carlosrg wrote:
        | >the existing convention
        | 
        | It is the existing convention, the Mac Finder convention.
        | And yes, it's effectively the same as cut and paste.
 
        | saagarjha wrote:
        | It's not permanently disabled, it enables itself when you
        | are editing text (for example, if you're renaming a
        | file).
 
        | chrisseaton wrote:
        | I think we're talking about copying-and-pasting _files_
        | in this thread, rather than text in input boxes, as you
        | 're thinking.
 
        | oneeyedpigeon wrote:
        | I think they mean cut+paste to move a file.
 
        | [deleted]
 
      | sercand wrote:
      | Copy, Cut, and Paste works just fine. I use the following
      | default shortcuts:
      | 
      | Cmd+C: Put file to Clipboard
      | 
      | Cmd+V: Copy file in Clipboard
      | 
      | Cmd+Option+V: Move file in Clipboard (aka Cut)
 
| alkonaut wrote:
| Note that _showing_ the thumbnails would likely be simple enough.
| The whole desktop system needs a system for generating and
| maintaining those thumbnails too. Those systems are always
| complex and messy (remember thumbs.db?)
| 
| A dialog that opens every file in the directory to read the image
| and show it, won't be very popular.
| 
| So implementing this feature isn't a change to a dialog but an
| implementation of something akin to the windows thumbnail cache
| https://en.m.wikipedia.org/wiki/Windows_thumbnail_cache
 
| apricot wrote:
| Comparing the GTK File chooser dialog to a clogged toilet is an
| insult to clogged toilets.
 
| its-summertime wrote:
| > Okay. Well, how much money should I pay for someone to fix this
| then? I'm legit offering a bounty here.
| 
| How much are you willing to offer?
 
  | michaelt wrote:
  | The problem with feature bounties is: $500 is a lot to give,
  | but not much to receive.
 
| pachico wrote:
| I read all the post hoping for a happy ending about the toilet
| issues.
| 
| Spoiler alert, there isn't such end.
 
| snvzz wrote:
| There's more serious reasons this file picker is broken.
| 
| Here's a trivial to reproduce and obvious issue that's been there
| for several years now:
| 
| 1. Open a directory that loads slowly (e.g. one with thousands of
| files on a smb3 mount)
| 
| 2. While the list is loading, select a file (but do not open it)
| 
| 3. Wait for the whole list to load
| 
| Once the list finishes loading, the file on the very top of the
| list gets automatically selected (discarding your selection).
| 
| Thus, if you select a file and click open, in the time between
| you select and click open, the selection can auto-change and
| you'll end up opening something else than what you've selected.
| 
| It is this bad.
 
  | ht85 wrote:
  | Let's do another... Open any directory with 3+ items. As first
  | item is highlighted, quickly hit , , . The 3rd item opens...
  | 
  | There is a lag when hitting  and the last 
  | is processed out of order :/
 
    | buckminster wrote:
    | This is bad but it's not unusual. There are similar issues in
    | Firefox and Windows. Nobody gets UI asynchrony right. There
    | are race conditions in everything. It's particularly
    | noticeable with a slow computer.
 
      | danaliv wrote:
      | I promise you people have gotten this right. I have a 198?
      | Mac Plus on my desk that I can boot up and do this on and
      | it will work properly. I'm having trouble even imagining
      | the insane event-processing architecture that results in
      | _keystrokes_ being processed out of order.
      | 
      | Edit: Alright, alright, forget the old computer. My new
      | ones get it right too. All of which is a red herring,
      | because the point is this behavior is ridiculous and never
      | should've shipped.
 
        | ivanbakel wrote:
        | >I'm having trouble even imagining the insane event-
        | processing architecture that results in keystrokes being
        | processed out of order.
        | 
        | It's relatively simple: the picker executes file-opening
        | asynchronously, and only checks which file was selected
        | at some indeterminate point after enter is pressed. In
        | the meantime, the down arrow input in the main GUI
        | changes the selection. The keypresses are always in
        | order.
        | 
        | Whether or not that's the correct decision, it's not an
        | inconceivable design. That example is probably one of the
        | only times it would matter, since you would need async
        | code that cares about some part of the file picker state.
 
        | ballenf wrote:
        | Why wouldn't the  key interrupt or freeze the
        | keypress queue? I don't think you need some advanced
        | async logic to get this right.
        | 
        | The only potential downside would be if people expected
        | to be able to cancel the  action. But that would
        | be unusual, I think.
 
        | freeone3000 wrote:
        | Why does the enter keypress save the relative index
        | instead of the actual target of the action? Even Windows
        | gets this one right.
 
        | buckminster wrote:
        | All old computers get it right. They are not doing UI
        | asynchrony. It's a fairly recent problem.
 
        | danaliv wrote:
        | My new computers get this right too. This is a design
        | flaw.
 
        | viraptor wrote:
        | That Mac cannot multithread the UI interactions. It
        | doesn't have to be a keystroke processing issue. It can
        | be "hey window parent, I've got your result in my
        | properties, pick it up" which doesn't get processed
        | before the next event changes the related property.
        | 
        | It's almost a classic TOCTOU issue.
 
        | [deleted]
 
    | tomsmeding wrote:
    | Incidentally, that lag is there independent of how fast your
    | disk is, it seems. It's kind of annoying.
 
  | MawKKe wrote:
  | Many years ago I was a hit by a bug in the Gnome file chooser
  | (on ubuntu) that selected a random sibling file in the same
  | directory. Caused me to accidentally upload something I
  | definetely didn't want to publish.
  | 
  | In fact I have never since directly uploaded anything from my
  | own personal file directories, instead I make a copy of it
  | under /tmp for the upload process.
  | 
  | Not sure if this is the same bug you are talking about
 
  | enriquto wrote:
  | Even worse is when you know the exact file name that you want
  | to open, and the interface fights against you writing it! For
  | example I want to open /tmp/a.png, but there's thousands of
  | files on /tmp and the cursor disappears while "loading" them,
  | and and some characters of the file name are lost, or typed on
  | different parts of the interface.
 
    | uncledave wrote:
    | That one really really really pissed me off because it's a
    | task I expect to do tens of times a day. Also it has some
    | serious focus loss issues in that space where you'll have to
    | tab or click something again.
    | 
    | I must have installed a Linux distribution 100 times with the
    | intent of using it as a desktop and lasted less than a day
    | every time. I've been doing it since 1998. Literally
    | something that horrible punches me in the face every time.
    | 
    | I refer back to my comment here:
    | https://news.ycombinator.com/item?id=25678434
    | 
    | I bought a Mac now. I'm too old for the fight.
    | 
    | Everything I do server side is on Linux but the desktop is
    | vile and I want no part of it any more.
 
    | kaszanka wrote:
    | Recursive search instead of type-ahead search within one
    | directory in the file picker is criminally terrible. I don't
    | think there is any implementation of a file picker that
    | behaves like this (other than Gtk's).
 
  | keyle wrote:
  | Right. So typical bug of redrawing selection once the list is
  | rendered.
  | 
  | On the plus side it should be an easy fix?
 
| p1necone wrote:
| Aren't there plenty of little UX niggles in macOS/windows just
| like this that haven't been fixed for years either? I'm not sure
| why this is being used as a reason why "Free desktop operating
| systems are a joke".
| 
| I think "use KDE" is perfectly valid advice here too. The toilet
| analogy doesn't really hold, your satisfaction of software that
| works for you shouldn't be at all affected by the existence of
| software you don't like and don't use, that's just silly.
 
  | saagarjha wrote:
  | The point is that there are fewer because people actually have
  | to use that UI that can't figure out workarounds.
 
| hedora wrote:
| This has somehow gotten worse in recent years. When saving, it
| used to be you could use the mouse to navigate to a directory,
| then type the desired filename, and press enter.
| 
| Now, typing the filename initiates a contextual search within the
| current directory.
| 
| Clicking in the filename textbox and starting to type doesn't
| work either. You have to highlight the base (not the extension or
| ".") of the filename. At that point, you can finally start typing
| the name of the file you want to save.
| 
| The same problem occurs if the file chooser happens to already be
| in the directory where you want to save the file.
 
  | deergomoo wrote:
  | I'm not sure if this is still the case as I haven't used
  | desktop Linux for about a year now, but what made this extra
  | irritating is that the file name would be highlighted already!
  | How on earth can selected text in an in-focus modal window not
  | be the target of keyboard input?
 
    | alpaca128 wrote:
    | For me this is really annoying as well, together with the
    | stupid text input fields that may display a blinking cursor
    | even when they're not focused. And Firefox has this weird
    | issue that now and then a newly opened tab doesn't focus the
    | address bar, forcing me to use the mouse to select it.
    | 
    | And I still don't get this trend in some newer software to
    | make tab switching via Ctrl-[Shift]-Tab feel like the lottery
    | instead of just going to the one on the left or right.
    | There's a reason we can reorder tabs by dragging them around,
    | and a reason our keyboards have more than just those three
    | keys, and "fidget cube replacement" is not it.
    | 
    | Sometimes I wonder if the UI designers never use their own
    | products or just aren't aware that building habits for chains
    | of workarounds should not be the normal way to interact with
    | computers. /rant
 
      | simon04 wrote:
      | Ctrl+L focuses the address bar. No need to lift your
      | fingers from the keyboard.
 
      | tomsmeding wrote:
      | > And Firefox has this weird issue that now and then a
      | newly opened tab doesn't focus the address bar, forcing me
      | to use the mouse to select it.
      | 
      | I'm not sure I have this issue, but ctrl-L (or
      | equivalently, ctrl-K) focuses the address bar. Less mouse
      | usage.
 
        | cesarb wrote:
        | If you keep them separate (it's configurable), Ctrl-L
        | focuses the address bar, Ctrl-K focuses the search bar. I
        | don't know how these keys behave if you configure it to
        | use a single combined address/search bar (I've always
        | kept them separate).
 
  | wizzwizz4 wrote:
  | Doing some introspection (all too rare for me!), I find that
  | this is the reason I've started avoiding creating new files in
  | LibreOffice, and why my Downloads and Pictures folders are
  | flat, unstructured messes. Too many programs use the GNOME file
  | selector.
 
    | Spivak wrote:
    | Isn't that "better" in some sense? You don't have to actually
    | categorize anything in order to find it later. Just type what
    | you want and let tracker pull it up for you.
    | 
    | If I could just "accio my black jeans" I wouldn't bother
    | organizing my closet.
 
      | wizzwizz4 wrote:
      | I suppose it might be better? But the folder-first sort
      | means I've got a miscellaneous pile of extracted archives
      | very far away from the archives themselves... it's a
      | complete mess.
 
      | nl wrote:
      | The assumes you know the _name_ of the random image you
      | downloaded to insert into the document.
      | _mjx3AmQXM5OrkxV7.jpg_ isn 't super easy to remember (as a
      | random real example chosen from my downloads directory)
 
  | [deleted]
 
| zapzupnz wrote:
| On macOS, when you drag a file into an Open or Save panel, the
| panel's current directory switches to the dragged file's
| containing directory and highlights that dragged file.
| 
| On Windows, when you drag a file into an Open or Save panel, the
| dragged file is _moved_ from its original location to the panel's
| current directory. It is a destructive action!
| 
| That may be one little thing but it's part of a whole number of
| reasons why I dislike using Windows. Alas, all the counter
| arguments to any and all reason I might give for preferring macOS
| do sound like toilet-plunging family members.
 
  | alkonaut wrote:
  | What's a save panel? You mean a save dialog?
  | 
  | Note that on windows there are at least 3 generations of save
  | dialogs. Which one you see depends on which generation of the
  | api is used.
  | 
  | The most common one is the more modern which is basically just
  | an explorer window. Dragging a file into an explorer window
  | works that same regardless of whether it's an open/save dialog
  | or not. It's a move/copy operation (depending on e.g modifier
  | keys).
  | 
  | I didn't quite get the point of dragging a file to a save
  | dialog at all though? (Assuming that's what you meant by panel)
  | is it that you _wanted_ to use it for navigate+set-name? That
  | to me as a windows user seems alien. I expect it to work as an
  | explorer window! Expectations are everything. The principle of
  | least surprise doesn't really work cross platform I guess.
 
| acgkmopvvgvmgv wrote:
| Pretty sure 99% of _regular_ people would be happy if there was a
| desktop with GNOME 2 feature parity but with a good Wayland
| compositor and probably some modern features that would come from
| that (multimonitor, VRR, ...).
| 
| I just can't understand how anyone could defend GNOME 3. Their
| own staff have to use extensions (that break every update), even
| Fedora (!!!) has to patch GNOME packages now.
| 
| They kept fighting that their workflow is superior and now they
| are going to change it all over next release. They keep
| butchering their toolkit, I can only use Qt applications now.
| Hell I'll take even Electron over GTK.
| 
| For me the Linux desktop with a WM is the perfect balance of
| exposing the internals and UX. It could be better but that's true
| to every OS, at least here I have my freedom. I'm keeping my eye
| on KDE, seems like they rewrote their less than ideal compositor
| (legacy X11 is a burden) and maybe in a year I could be using
| that.
| 
| I've once heard someone say that GNOME is Microsoft's favorite
| DE. You can guess why.
 
  | ansible wrote:
  | > _...but with a good Wayland compositor..._
  | 
  | Up until 2020, I didn't use screen sharing all that much, so
  | the lack of support for that wasn't a big deal with using
  | Wayland.
  | 
  | Now days though... this is a problem. I feel sorry for the
  | folks running some Linux desktop that don't know why the option
  | to start screen sharing just doesn't exist in various apps. I
  | can imagine another Linux user saying "but it is right there!"
  | to them, also not understanding why they have it but the person
  | they're talking to does not have screen sharing.
 
  | nightfly wrote:
  | Have you looked at MATE? https://mate-desktop.org/
 
    | twic wrote:
    | Or Cinnamon:
    | 
    | https://projects.linuxmint.com/cinnamon/
    | 
    | I've been running Cinnamon on a few machines for years, and
    | it mostly works fine, which for a Linux desktop is high
    | praise. The file picker has thumbnails (although it only has
    | a list view, so they're ant-size).
    | 
    | I haven't used MATE. My understanding is that MATE started
    | life as Gnome 2, whereas Cinnamon started life as Gnome 3
    | reskinned to look like Gnome 2. Both have grown considerably
    | from their starting points.
 
    | zapzupnz wrote:
    | And somewhat related, TDE is the KDE 3.5 of the modern era.
    | https://trinitydesktop.org
    | 
    | (I say modern era; it's more or less just recompiled. Still
    | comes with some of the yuckiness of days gone by, like aRtsd
    | for audio.
 
  | phkahler wrote:
  | >> Pretty sure 99% of regular people would be happy if there
  | was a desktop with GNOME 2 feature parity but with a good
  | Wayland compositor
  | 
  | You mean like the ability to put things on the desktop? There's
  | even a desktop folder, but well....
  | 
  | I use gnome and I agree with you.
 
| stephen82 wrote:
| Install PCManFM and that will do; an extremely lightweight File
| Manager which I happen to use parallel with Thunar.
 
  | ubercow13 wrote:
  | This post is about the Gtk file picker, not file managers.
 
| turminal wrote:
| And despite all such issues everyone still has the time to argue
| about things like stopthemingmy.app
 
| ehutch79 wrote:
| It's open source.
| 
| I'm sure they're accepting pull requests.
 
  | bsdubernerd wrote:
  | Not really. This is not the first or the last one fixing
  | horrible behavior in the default file picker.
  | 
  | Most of the time there's a deliberate reason the picker was
  | designed this way, and the GNOME team won't accept your patch.
  | 
  | I personally stopped contributing to GTK very late in the GTK 2
  | series with very similar problems, and stopped using GTK in my
  | projects since GTK 3.
  | 
  | GTK used to be my favorite toolkit back in the day.
 
| agurk wrote:
| So I just checked on my install (Gnome 3.38.2, Debian testing)
| and all the GTKFileChooser windows I could find had the
| thumbnails representing the underlying images.
| 
| Interestingly I checked a few apps I have installed through
| Flatpak, and they generally didn't have thumbnails for the same
| dialogues, although sometimes did for the "recents".
| 
| Unless this has been recently added as a feature, it sounds more
| like he has another issue affecting his desktop rather than
| outright missing functionality. Or could this be a Debian applied
| patch? I couldn't find any details after a quick google.
 
  | ubercow13 wrote:
  | Can you provide a screenshot?
 
    | agurk wrote:
    | If you read the article more closely than I did originally
    | there is an example of what I see in their original article
    | [0]. The thumbnail is part of the list view and they want to
    | see a thumbnail without the other file details.
    | 
    | [0] https://jayfax.neocities.org/mediocrity/gnome2.png
 
      | fvdessen wrote:
      | We want to see all the thumbnails at once, not just the
      | selected one.
 
        | agurk wrote:
        | The screenshot from the article is very low resolution,
        | so it's quite hard to see if you don't know what you're
        | looking for, but it does have a unique thumbnail against
        | each filename.
        | 
        | The underlying complaint is that people want this to be
        | bigger.
 
      | ubercow13 wrote:
      | Yes, they are so small that they are completely useless.
      | What is needed is a widget like the one from Windows at the
      | top of the article that actually shows all the thumbnails
      | at a decent size so you can use them to actually locate the
      | right image.
 
  | agurk wrote:
  | After a downvote encouraged me to re-read the article more
  | carefully it seems the OP wants to be able to see only the
  | thumbnail (and maybe the filename) - not a thumbnail that is
  | part of the list view with further details.
  | 
  | Older builds of Gnome only seemed to use the generic icon for
  | the file type, so it does sound like there has been progress
  | here - if not enough to satisfy the OP.
 
| johnchristopher wrote:
| > One might also say "Just use KDE!" Yeah, I guess I could use
| KDE, just like I use the downstairs toilet instead of the other
| ones.
| 
| Yeah but when you the downstairs toilet you can't bring in your
| favourite newspaper because the paper its printed on isn't
| compatible with the light bulb and you can't read it.
| 
| Firefox on KDE uses the GTK filepicker. No thumbnails.
 
  | heavyset_go wrote:
  | > _Firefox on KDE uses the GTK filepicker. No thumbnails._
  | 
  | Not if you set the GTK_USE_PORTAL environment variable.
  | $ GTK_USE_PORTAL=1 firefox
  | 
  | The above will make Firefox use the KDE filepicker.
 
    | corty wrote:
    | So they say. But I could never get that to work, with
    | KDE/Plasma the dialog just never shows up.
 
      | heavyset_go wrote:
      | An AppArmor rule used to prevent it from working on my
      | system.
 
  | nisa wrote:
  | > Firefox on KDE uses the GTK filepicker. No thumbnails.
  | 
  | Not true. Firefox on current Arch/Plasma works fine with the
  | KDE filepicker.
 
    | johnchristopher wrote:
    | It's completely true on Kubuntu 18.04. Ah !
    | 
    | now that I think about it I remembered a little trick
    | https://askubuntu.com/questions/1100261/how-do-i-make-
    | firefo... Have to try it again.
 
| 0xbadcafebee wrote:
| OSS is not designed to solve user problems, it's designed to
| solve developer problems. Therefore it will always suck compared
| to a commercial product developed for users. Good product design
| solves users' problems. ( _And_ usually there 's somebody who
| will get fired if they wait indefinitely to solve it)
 
  | bsdubernerd wrote:
  | As a dev I still have to interact with the file picker a huge
  | number of times in a single day. The GTK file picker is perhaps
  | one of the worst offenders that's irritating devs, power-users
  | and plain regular users.
  | 
  | Patches get dismissed.
  | 
  | I don't know where the problem is. It's as if the GNOME team
  | had a vision, but didn't actually try to see how this vision
  | plays out using the tools they're making.
 
| mseepgood wrote:
| It's a design decision. There is no right or wrong.
 
  | corty wrote:
  | There are design decisions that are wrong. Invisible emergency
  | exit signs are a wrong design decision. Making the emergency
  | off button the same color and shape as the light switch is also
  | a wrong design decision. And yes, I think the original problem
  | is also a wrong design decision.
  | 
  | Design isn't just art, design of functional objects needs to be
  | functional. That means that there is a objective criterion for
  | wrong design: if it isn't functional, it's wrong.
 
  | viraptor wrote:
  | It's a design decision if both sides have competing benefits
  | and you choose one. In this case it's a planning / engineering
  | decision: other work is prioritised higher than implementing
  | the previews.
 
| senko wrote:
| Users like these are why maintainers of open source software are
| burning out.
 
  | ornxka wrote:
  | If people are going to make crappy half-baked software that
  | doesn't work, they need to be upfront about it so people stop
  | expecting it to do its job. If they're not going to do this,
  | people are right to expect a basic level of quality and to
  | complain when they don't get it.
 
    | etaioinshrdlu wrote:
    | It also doesn't help that theres an utter legion of Linux
    | users who deny that the ecosystem has any deficiencies at all
    | compared to windows and macOS. It's so misleading.
 
      | vetinari wrote:
      | All three have deficiencies, and for all three you will
      | find people claiming that their chosen one is best thing
      | since sliced bread.
      | 
      | No need to single out a specific one.
 
  | rayrag wrote:
  | No it's not users, it's open source developers are guilty
  | themselves. There is no need to have dozens of Linux distros,
  | multiple packages, few desktop environments (with apps like
  | email clients, music players, etc. created for each
  | environment). Windows doesn't have multiple desktop
  | environments to choose, Microsoft isn't developing multiple
  | email clients and so on. The amount of wasted time (creating
  | multiple solutions for one problem) in Linux world is
  | staggering.
 
  | londons_explore wrote:
  | These user complaints are 100% legit...
  | 
  | But we need some good funding model to pay someone to fix them.
  | Good funding models are something the opensource world has been
  | missing for a while...
 
    | viraptor wrote:
    | The complaint is legit. But making a page about your pet
    | issue to create emotional response and cause rants about
    | gnome on social media? That's annoying.
    | 
    | Here's a better structure for the post "This is an issue that
    | really impacts me and I care a lot about. See existing bug /
    | discussion links. I can't solve it myself, but it's important
    | enough that I'm willing to put up bounty for that work." I
    | don't think anyone would complain about it.
 
      | londons_explore wrote:
      | I don't think the author cares about _this_ issue.
      | 
      | The author is trying to point out a process problem in the
      | hope that some of us here at HN can help solve it.
 
    | onli wrote:
    | I wouldn't be confident that funding is the solution here.
    | This is about adding a feature to a project that seems to be
    | completely disinterested in that feature, some recent answers
    | from project developers in the gitlab issue are even hostile
    | to it. Likely to be not something money can fix, this goes
    | directly into the deep rooted problems GNOME has with
    | usability.
 
    | xgbi wrote:
    | He IS actually offering a bounty, though..
 
      | wizzwizz4 wrote:
      | "There's some hypothetical money to claim from somebody,
      | somewhere" is not a good funding model. At best, you'll get
      | a dozen additional issues sorted in a large project.
 
  | ravenstine wrote:
  | It's a pretty basic feature for a modern file manager.
  | 
  | The way I see it, maintainers like these are why users of open
  | source software are burning out and switching to macOS.
 
| TaylorAlexander wrote:
| I have a lot of issues with gnome on the latest Ubuntu. When you
| open a folder with icon view, sometimes loading the folder just
| stalls. You have to go back and open it again and then it's fine.
| Also selecting multiple items with ctrl click only works in list
| view. There's some bug in icon view where when I click on an item
| it instantly scrolls my window and selects something else. It's
| honestly weird that this basic aspect of file browsing is so
| broken. I do wonder too if I've broken my system or if it always
| behaves this way.
| 
| As an aside right now I'm designing a part in the free version of
| the commercial software OnShape and I just discovered it does not
| support scaling a sketch. There is a long support thread going
| back 5 years of people asking how to do this and recommendations
| for elaborate workarounds. I decided to export the sketch as a
| drawing, open it in the free and open source program QCAD, select
| everything and choose the "scale" option, scale as desired, save,
| then upload to OnShape.
| 
| FLOSS needs to be better than this but as someone else said
| commercial software has issues like this too. The reality I think
| is that we need to look at how to better fund open source, as
| time strapped teams aren't super functional in general.
 
| lrossi wrote:
| Meanwhile, Qt seems to have the same issue:
| 
| https://bugreports.qt.io/browse/QTBUG-3796
 
  | jcelerier wrote:
  | thumbnails work in kde tho:
  | https://www.google.com/search?q=kde+thumbnail+file+dialog&tb...
 
| arnaudsm wrote:
| Bounties can be a great way to stimulate open-source projects!
| You can use BountySource or IssueHunt to create one.
 
| londons_explore wrote:
| Death by a thousand small inefficiencies, quirks and bugs...
| 
| It's such a shame, because fixing most of these small bugs is far
| less work than building new features. Nobody wants to put the
| work in though... Nobody has the overarching vision of a
| consistent UX that just works out of the box without oddities,
| quirks and workarounds.
 
  | noncoml wrote:
  | > Death by a thousand small inefficiencies, quirks and bugs...
  | 
  | I agree, this is the problem. GUI OS developers like to work on
  | big features and eye candy but forget to fix the basics. I have
  | yet to find a Window system that:
  | 
  | 1. Works without glitches in HiDPI setups. Especially mouse
  | pointer glitches.
  | 
  | 2. Comes out of the box with fonts that don't feel like thorns
  | in the eyes, including the browser.
 
  | oh_sigh wrote:
  | Part of the reason no one wants to put in the work is because
  | all it takes is a technical dictator to say "I don't like this
  | approach, let's rethink this", and scuttle your weeks of work.
  | Even if you got a sign-off on the approach earlier. This has
  | happened enough times to me in open source projects that I only
  | submit code to projects that I know have reasonable maintainers
  | that I've interacted with in the past.
  | 
  | Developers frequently hate it when "product people" get a say
  | in the direction of the product, but the alternative is
  | commonly to have developers prioritize perceived code purity
  | over actual user interests. And emphasis on "perceived",
  | because usually the codebase is a hot mess but maintainers want
  | it to be _their_ hot mess, not someone else 's.
 
| ilaksh wrote:
| Maybe I will switch to KDE. Does the file picker in Chrome use
| that if I am running KDE? Someone said you have to trick Firefox
| in that case to not use GTK.
 
| lol768 wrote:
| Sounds like there is already a working patch on GitHub, but it's
| not been reviewed because an MR wasn't opened on GitLab?
 
| ChrisMarshallNY wrote:
| That is a great metaphor, and pretty much nails why so many
| tecchies have difficulty with true usability.
 
| johannes1234321 wrote:
| Gnome uses Gtk; Gtk is the Gimp Toolkit. It was created for an
| image editing program. In a way funny that their file picker is
| missing such an feature one would expect in an image editing
| program these days.
| 
| (From scrolling offer the discussion I can in parts see the
| architectural constraints they have and can image they have other
| priorities ...)
 
| reddotX wrote:
| no desktop, no system tray icons.. gnome is a joke
 
  | amiga-workbench wrote:
  | Tools and features have ergonomics and affordances that suggest
  | a certain way of using them, and desktop filling just seems to
  | encourage people to make a massive mess. Even when I was a
  | Windows user, desktop icons were the first thing to go. Not
  | having quick access to a dumping ground meant that I had to go
  | out of my way to make a mess.
  | 
  | As for a lack of system tray icons, the practical upshot is
  | that my system bar isn't littered with multiple special
  | snowflake applications, each with their own unique icon art
  | style and mismatching proportions.
 
    | heavyset_go wrote:
    | > _As for a lack of system tray icons, the practical upshot
    | is that my system bar isn 't littered with multiple special
    | snowflake applications, each with their own unique icon art
    | style and mismatching proportions._
    | 
    | Plasma Desktop's System Tray widget that lets you hide icons
    | you don't want to see. You can disable the widget, or
    | configure it to show no icons at all.
 
    | inshadows wrote:
    | Your kind is a minority. 99.9% of Windows users keep desktop
    | icons.
 
| seltzered_ wrote:
| Reminds me of a different story involving Bill Gates, toilets,
| and user interface design:
| https://web.archive.org/web/20120427101911/http://jacksonfis...
| 
| "At one particularly frustrating moment, I offered the following:
| "Bill, a shower, a toilet, and a water fountain all have
| mechanisms to control water flow, places where the water comes
| out, some sort of porcelain basin to hold the water, and a drain,
| but we don't combine them into one thing to reduce their learning
| curve. We don't merge them into one object because each of them
| are in use in fundamentally different ways at different times."
| 
| Then the pause.
| 
| Then Bill's verdict. ["That's just rude."]
| 
| Ouch.
| 
| As I saw my career disintegrate before me, I started to question
| just how "beautiful" my analogy really was. To his credit, Bill
| was forgiving, and met with me many times after that, giving me
| numerous opportunities to get him on board with all manner of
| ideas coming from my team (with varying degrees of success on my
| part). Ultimately, I never did succeed in making Bill really
| comfortable with a more emotional approach to software design.
| But the real lesson of the day was learned. In the software
| industry, as long as the engineering-minded run the show, the
| notion of subtle and textured user experience design that
| balances the emotional and functional aspects of a software
| experience will always struggle to take root."
| 
| --
| 
| I keep a running list of little workflows and experiences I
| generally love on macOS and see if alternatives exist here:
| https://docs.google.com/spreadsheets/d/148zTJUwfVv9xfDcpSoH3...
 
  | hitekker wrote:
  | Great anecdote. The outrage in its comment section indicates
  | the author struck a nerve.
 
| etaioinshrdlu wrote:
| This brings up a great point about GNOME. GNOME appears to try to
| emulate macOS at times, but tends to try to oversimplify and
| paradoxically be quite user-unfriendly.
 
  | curt15 wrote:
  | GNOME has an obsession with a "distraction-free" interface that
  | really takes keyboard shortcuts to navigate efficiently. For
  | example, despite the popularity of the dash-to-dock extension,
  | the GNOME developers stubbornly refuse to make the dock built-
  | in. So with the default setup, mouse users (like many in my
  | family) need two large cursor movements (flick to the left
  | corner, then slide down to the dock) every time they need to
  | switch between applications[1]. In fact, at least one core
  | developer has even floated the possibility of removing the dock
  | and its list of currently running apps altogether.
  | 
  | [1] No, the window previews aren't really useful because their
  | positions are non-deterministic and it's hard to rapidly
  | distinguish mostly white, unlabeled windows anyway.
 
| renewiltord wrote:
| Hahaha this made me realize a workaround I use. I always drag and
| drop from Nautilus to upload. Hahaha oh man. Talk about being
| trained by inferior tooling.
 
___________________________________________________________________
(page generated 2021-01-10 23:00 UTC)