|
| 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) |