GNOME has no thumbnails in the file picker and my toilets are blocked • Hacker News Board

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

#391

Post by addicted » Mon, Jan 11, 2021, 1:54 AM UTC

cycloptic wrote: post #347

baybal2 wrote: post #342

Earlier quoted context omitted.

> If you are a developer and you don't agree with direction changes, you don't have to work on them I would tell the same to Poettering, Clasen, and co. There is really nobody who obligates them to work on their "innovations" in GNOME with religious zeal if the rest of the project showed no interest, speaking lightly. If nobody wants to work on their stuff, they can't claim "victimhood" as if that happens as a result…

I would advise holding off judgement on specific individuals unless you have worked with them closely and you have a deep understanding of why certain decisions were made. Again, if you are a developer and you disagree with someone's choices, you are free to take it in your own direction. You do not have to work on anybody else's stuff if you don't want.

This advice definitely applies to open source developers whose work is out completely in the open.

You can literally take millions of lines of code that they may have written wholesale, and change a single word in it that you don’t like.

In open source, they have nowhere to hide. If you disagree with a certain decision they have made, you are welcome to take the effort they have put in to implement the hundreds and thousands of other decisions they have made that you do agree with, with a simple “git clone”.

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

#392

Post by zapzupnz » Mon, Jan 11, 2021, 1:57 AM UTC

Tijdreiziger wrote: post #312

zapzupnz wrote: post #193

Earlier quoted context omitted.

Yes, a save panel is a save dialogue. It’s just Apple terminology. > I don’t quite get the point of dragging a file to a save dialog at all though? On macOS (since forever) and iOS (since 11), there is a heavy focus on drag. You should be able to drag anything from any app to any other app and something should happen. This is facilitated both by system-level frameworks (so that all apps can gain correct drag-handling…

> So, imagine I have a browser window open asking me to upload a file. If I have that file open, why should I navigate the directory hierarchy in the open panel? I can just drag the proxy icon for that document straight into the open panel. Bam, the open panel is pointing at the correct location. On Windows you can drag the file right onto the 'Browse...' button on the web page. (this does require some precision, as…

> On Windows you can drag the file right onto the ‘Browse…’ button

I know, but I was illustrating a point about how the open/save panels work. That’s why in the following example, I mentioned that I’d just drag straight into the app.

> Perhaps I’m too used to Windows’s idiosyncrasies

Yes, you are. If you want an Explorer window, you should open Explorer. When you see a file picker dialog, you don’t see an extra Explorer process spawn nor does that dialog get added to Explorer’s list of windows.

> This does not seem surprising to me

Because you’re looking at it from a technical level, not a user interaction level.

At the interaction level, what is the goal of an open/save panel? To pick a location. It doesn’t fundamentally need to do or be anything more than that. That its default behaviour is destructive is classifiable as ‘surprising’.

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

#393

Post by snvzz » Mon, Jan 11, 2021, 1:58 AM UTC

tylermenezes wrote: post #203

formerly_proven wrote: post #184

Earlier quoted context omitted.

Picking directories has been pretty broken forever as well. Say you start in ~/Downloads/foo and want to store the file in ~/Downloads, then navigating up will have "foo" selected, with usually no blank space to un-select (so you'd need to do ctrl+click or something to that tune); clicking "Save" (or whatever) will then descend into that directory instead of saving, so just using the mouse, or not using any shortcuts…

Wow I never thought about Ctrl+Click to deselect in that situation. I've probably wasted at least an hour of my life by giving up and re-opening the window in a different way. Thanks! (I actually asked someone more knowledgable about this once and was told that it's my fault for using the file picker incorrectly and I simply need to stop doing that.)

I tried C-shift-A, but didn't work.

Control click seems to work.

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

#394

Post by zapzupnz » Mon, Jan 11, 2021, 1:59 AM UTC

williamscales wrote: post #290

zapzupnz wrote: post #193

Earlier quoted context omitted.

Yes, a save panel is a save dialogue. It’s just Apple terminology. > I don’t quite get the point of dragging a file to a save dialog at all though? On macOS (since forever) and iOS (since 11), there is a heavy focus on drag. You should be able to drag anything from any app to any other app and something should happen. This is facilitated both by system-level frameworks (so that all apps can gain correct drag-handling…

Thanks for this great comment! As a non Mac person who has occasionally used a Mac, it makes perfect sense. > The only thing I expect to act as an Explorer window is … an Explorer window. One thing I wanted to add from my perspective (software engineer, use Linux and Windows): if I observed that the “save” button had created a literal Explorer window, then I think I would expect it to function as a Explorer window. I…

If the “save” button did indeed create a literal Explorer window, I expect it to come with all the trimmings — but it doesn’t. Plenty of what makes Explorer what it is aren’t part of the actual control that both Explorer and file picker dialogs use.

To me, thinking of file picker dialogs as literal Explorer windows is as contrived as file picker dialogs not offering full CRUD abilities — except one approach is vastly friendlier and safer.

I understand the technical decision, too, but there’s nothing that could prevent Windows from making file picker dialog behaviour non-destructive.

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

#395

Post by cycloptic » Mon, Jan 11, 2021, 2:00 AM UTC

stretchcat wrote: post #362

cycloptic wrote: post #347

Earlier quoted context omitted.

I would advise holding off judgement on specific individuals unless you have worked with them closely and you have a deep understanding of why certain decisions were made. Again, if you are a developer and you disagree with someone's choices, you are free to take it in your own direction. You do not have to work on anybody else's stuff if you don't want.

> I would advise holding off judgement on specific individuals unless you have worked with them closely and you have a deep understanding of why certain decisions were made. Is this advice meant to be applied against all people, or just other developers? I certainly wouldn't apply this standard to RIAA lawyers suing kids. I judge them to be worms even though I never worked with them. And don't even get me started on…

For me, it applies to everyone. I try hard to not hold a grudge. It's difficult but emotionally rewarding.

If we are trying to be good open source citizens and avoid unnecessary fights, you can apply it just to that.

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

#396

Post by jfim » Mon, Jan 11, 2021, 2:01 AM UTC

tsukurimashou wrote: post #364

tylermenezes wrote: post #203

Earlier quoted context omitted.

Wow I never thought about Ctrl+Click to deselect in that situation. I've probably wasted at least an hour of my life by giving up and re-opening the window in a different way. Thanks! (I actually asked someone more knowledgable about this once and was told that it's my fault for using the file picker incorrectly and I simply need to stop doing that.)

One thing I was happy to discover as a kid was shift + tab to go backwards with input selection (Spacebar to trigger checkboxes was nice too)

These shortcuts have been a thing for quite a while too, they come from the IBM CUA guidelines [0].

[0] https://en.m.wikipedia.org/wiki/IBM_Common_User_Access

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

#397

Post by danmur » Mon, Jan 11, 2021, 2:04 AM UTC

jdright wrote: post #156

swebs wrote: 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 think that's very much personal preference. I tried KDE a few months ago and I couldn't stick with it; it is slower than Gnome in a lot of ways, it's (to my eyes) much more cluttered, and has lags at annoying places. For example, I tend to hit the windows key and start typing to launch things, but under KDE there's enough lag before the menu opens that it doesn't catch my first few keypresses.

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

#398

Post by tkuraku » Mon, Jan 11, 2021, 2:06 AM UTC

hedora wrote: post #29

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

This is the most maddening behavior. I don't really care about the thumbnails not being there, but this irks me evertime I save a file.

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

#399

Post by rablackburn » Mon, Jan 11, 2021, 2:09 AM UTC

Jedd wrote: post #377

The author unfairly attributes adequacy (or at least consistency) to the Microsoft desktop environment. Start Microsoft Windows, open up File Explorer, remove the ever-present 'Type' column (because if you're old school you'll have suffixes enabled), then go to Options and say 'Save this view format for ALL Explorer instances'. Within an hour you'll have a Type column back in some new Explorer window, to inform you t…

I don't think the author attributes universal consistency to Windows? They just say that this particular issue has been 'solved' by Windows since 1998. It's been raised as an issue in Gnome since 2004 and still hasn't been fixed.

I agree with most of what they say, and I think the point is that we're uniquely bad at addressing these issues in the open-source world.

We accept a degraded UX experience (which I think this unarguably is from a normal user's point of view) because at least it's not proprietary lock-in. But it's a big reason why desktop GNU/Linux doesn't crack 2% usage. Inversely, I think this is _the_ core value proposition of Apple's ecosystem. They pay particular attention to consistent, unsurprising integration, and the Apple experience offsets their iron-grip over your device for most users. It's easier to convince someone to change how they do a task if you consistently deliver pleasant UX.

I recently had the opportunity to help a _very_ 'normal' user with their computing, and it was remarkably eye-opening watching them interact with their machine (Windows at the time, but they also use a Mac). Indeed, they hated Windows because it wasn't as consistent as a Mac, but Windows was dealing with their ambiguous interaction remarkably well I thought. Much better than a GNU/Linux DE would have.

If we want a world where normal people can use free software for their everyday computing needs this is something we need to get much better at. Forget 'normal' users even, these projects (and threads on HN) are full of _developers_ arguing back and forth that they find it infuriating/unusable. And unfortunately not many of us have the time and money to contribute code or fork projects to increase competition and spur improvements.

(also, hi again Jedd :) )

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

#400

Post by zapzupnz » Mon, Jan 11, 2021, 2:12 AM UTC

PaulDavisThe1st wrote: post #329

zapzupnz wrote: post #193

Earlier quoted context omitted.

Yes, a save panel is a save dialogue. It’s just Apple terminology. > I don’t quite get the point of dragging a file to a save dialog at all though? On macOS (since forever) and iOS (since 11), there is a heavy focus on drag. You should be able to drag anything from any app to any other app and something should happen. This is facilitated both by system-level frameworks (so that all apps can gain correct drag-handling…

> On macOS and iOS, it’s not just built into every app, it’s built into the operating system itself. It’s a fundamental feature of Cocoa, open which all native apps are built, so every app gets the correct behaviour for free. Dragging and dropping is super powered on Apple platforms. This isn't true. It is true that it's built into the development tools and toolkits that Apple provide and expect you to use when writi…

My only response to that is apps that aren’t made to be good macOS citizens wouldn’t even vaguely register on my radar as ‘native’, even if they link against Cocoa.

‘Native’ on Apple platforms isn’t just a technical description, it’s also about UI and, more importantly, UX. Of course, Apple are starting to muddy the waters with UIKit for Mac — but even then, the fact that iOS apps can now run ‘natively’ on macOS goes a long way to showing that just because an app links against the relevant frameworks compiled for the right processor architecture, that doesn’t make it native in the Apple-y sense.

Apps made using cross-platform frameworks like Qt and GTK certainly don’t register to me as native. They don’t just work differently, they even look odd. I don’t think this fazes Windows and Linux users/developers as much because there has never been any level of consistency remotely close to what Cocoa and macOS offers — if an app puts a few buttons in a slightly odd place, that’s not seen an a problem.

So I agree with your point on a technical basis that my assessment wasn’t 100% technically true — but I think from the point of view of what ‘native apps’ means when discussing Apple platforms, I don’t think I’m too far off the mark.