Live data from Hacker News

GNOME has no thumbnails in the file picker and my toilets are blocked

jayfax.neocities.org

291–300 of 756 posts

Re: GNOME has no thumbnails in the file picker and my toilets are blocked

#291

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 w…

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…

Disclainer: KDE dev so take my opinion with a pinch of salt :p

The decision by the Ubuntu Studio variants was made by the Ubuntu Studio developers and not by Canonical. The developers are also maintaining Fedora Jam with KDE installed by default too. Unfortunately all the big commercial distros are using GNOME as default DE because RedHat is providing the commercial support for GNOME already and it's easier for them to just make the same choice. So I don't think Ubuntu will switch to KDE anytime soo, even if GNOME developers don't like Ubuntu and make their opinion very public.

For those interested on why artists like Plasma so much, David Revoy made a nice summary: https://www.davidrevoy.com/article783/kubuntu-linux-20-04-fo....

Re: GNOME has no thumbnails in the file picker and my toilets are blocked

#292
post #27

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 automatical…

GUIs should effectively be finite state machines and people expect them to operate that way. People understand latency and get used to it; it happened on mainframes and other terminal applications and people memorize the state machine and can tab and type through an interface at high throughput anyway. One of the most frustrating experiences is related to the OP; reflow in browsers as new elements load making it impo…

Some folks use this fact to place ads in such way that when you want to click something by the time your finger taps the screen there is an ad underneath. So annoying.

Re: GNOME has no thumbnails in the file picker and my toilets are blocked

#293
post #36

Earlier quoted context omitted.

At least enough people care that its become a meme in some tech communities. https://wiki.installgentoo.com/wiki/File_Picker_meme

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.

I find KDE to be pretty ugly.

For instance, margins and paddings seem to be all over the place [1]. At least Gnome gets that part right.

[1] https://community.kde.org/Plasma/Notifications

Re: GNOME has no thumbnails in the file picker and my toilets are blocked

#294
post #153

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…

> Gnome aspires to that, but lacks Apple's reality distortion field, so must make do with contempt.

The difference is that GNOME can be fixable with a few settings tweaks and patches, the same can't be said about MacOS.

Re: GNOME has no thumbnails in the file picker and my toilets are blocked

#295

As a KDE user I wouldn't care what the Gnome people do if their BS wouldn't affect me. But it does, and it's annoying! They refuse since over a decade to implement some generic way to open the file-picker native to the running DE. They force their garbage usability on everybody, even people that would prefer not to use "anything Gnome". Same issue with CSDs, by the way. Like I said: They can have their broken stuff a…

Somehow I feel pity for Gnome users. It reminds me of the early KDE 4 days, just that they seem to be stuck in this limbo for a much longer time. Gnome 3 was released in 2011...

Re: GNOME has no thumbnails in the file picker and my toilets are blocked

#296

Earlier quoted context omitted.

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.

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?

>Why completely break the existing convention?

Because cutting-and-pasting is a destructive action that can lead to data loss.

Under the conventional implementation of cut-and-paste, it's easy for a user to inadvertently cut-and-paste a file, when they meant to copy-and-paste said file, either through a misclick or, by hitting the wrong keyboard combination. This is because:

1. The menu option for cut is right above the menu option for copy

2. The keyboard shortcut for cut (command-c) is just one key away from the keyboard shortcut for copy (command-c) on a QWERTY keyboard

Cutting and pasting deletes the file from its original directory, however under a traditional cut-and-paste operation, the system does not ask for confirmation. Consequently, if a user mistakenly cuts a file or directory without immediately noticing their mistake, their files could be rendered unrecoverable (and keep in mind that there's no particular reason why they would notice... the UI provides no special indication when a file or directory is deleted via cut-and-paste). This is arguably a very bad user experience.

The equivalent action to cutting-and-pasting on OS X is copying, pasting and then deleting the original file. By adding in this extra step, the UI has forced users to acknowledge that their action is potentially destructive and unrecoverable.

Also notice that the command-x shortcut in Finder copies a file. It does not cut the file. Again, this protects the user from inadvertent data loss if they use the wrong keyboard shortcut.

It's a rather unusual move Apple has made here by breaking convention, but I think they've made a wise wager that users would rather be annoyed by a small extra step, then be faced with the loss of important data.

Thinking about this design choice, I now wonder how many times I've had files mysteriously go missing on Windows and other operating systems simply because I used CTRL+X when I meant to use CTRL+C

Re: GNOME has no thumbnails in the file picker and my toilets are blocked

#298

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 w…

> 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 wr…

There is a lot going on each week in KDE trying to improve the situation. Nate Graham is making a summary of the parts, he monitors: https://pointieststick.com/ There is definitely still quite a bit to improve but compared to 3 years ago, Plasma and KDE software has improved by a lot.

Re: GNOME has no thumbnails in the file picker and my toilets are blocked

#299

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 c…

There was a paragraph in that article that made me think of something

>”But engineers (like everyone) see the world through their lens. Engineers look at code all day. And when they see two pieces of code doing roughly the same thing, they immediately think about ways they could eliminate the wasted effort by combining them into one piece of code that performs both functions”.

I shudder when thinking of all the times I have wasted time trying to generalize something only to end up with code that is harder to understand, awkward to use, more complex, more prone to bugs, or all of the aforementioned, just because there is a stupid voice in my head going “do not repeat yourself”.

With maturity comes the insight that not repeating yourself is good. But sometimes avoiding it makes things worse and costs a lot more.

Re: GNOME has no thumbnails in the file picker and my toilets are blocked

#300

Earlier quoted context omitted.

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 si…

I've never noticed such issue, quick search shows that one has to start on edge and movement in vertical direction [1]. Vanilla edges are 8% of the width on each side [2]. There was a proposal to add configuration option [3], rejected — they've tried this route before, it was impossible to test. Fortunately source is there and it is easy to patch (try to set 0%). That's quite common, for example there are several pat…

Thanks for your detailed reply. Unfortunately the Microsoft Precision Touchpad on my Dell XPS 2-in-1 2019 (Wacom HID 48EE Finger) does not support ABS_MT_TOUCH_MAJOR; it's worth mentioning however that Windows works perfectly and palm rejection seems to work on a hardware/firmware level (no output when running "libinput debug-events" and moving a palm) making libinput restrictions unnecessary and most definitely unwanted.

The touchpad is about 7 fingers in width and the palm exclusion zones are a little more than one finger on each side; this is roughly 30% of the trackpad, or 15% each side, certainly bigger than 8% and even that would be too much.

Additionally, although the documentation does state that rejections should only happen for a vertical like movement, it also happens for a completely horizontal one.

Post reply on HN