Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

File picker meme

wiki.installgentoo.com

Post reply on HN
Print view View original

61–70 of 130 posts

Re: File picker meme

#61

Post by jdub »

This issue is almost never raised in good faith. Just look at this document. Disingenuous, trolling, contemptuous of the work of FLOSS developers. Then look at the comments in this thread, repeating and escalating the same nastiness.

Crap like this contributes to burnout, people leaving the community, etc. Why spend your time on a volunteer effort if you're just going to be abused by non-contributors?

There's a reason behind the problem should anyone care to find out...

Most people reading this thread should have at least some sympathy (empathy, even) for architectural and social challenges in large, long-running software projects.

GNOME is a 22 year old project, and for much of that time its underlying toolkit, GTK (formerly GTK+), was intentionally maintained very separately. The consequence is that, broadly speaking, GTK could not depend on GNOME features.

So, shoving GNOME's Nautilus-powered file management in a GTK file chooser? That's tricky. Other GTK users would not appreciate GTK depending on, well, almost all of GNOME.

A point of integration was required, to allow the outside environment to provide the file chooser user interface. Turns out that's also tricky, especially when your toolkit is providing API/ABI guarantees. Consider that GTK 2.x maintained API/ABI compatibility for almost half the entire lifetime of the GTK project.

But no one gave up. More recently, the XDG portals work provides an opportunity to solve this (and quite a few other problems) cleanly and, more importantly, securely. This will also allow a KDE environment to provide the file chooser interface for a GTK application. Nice! Why isn't it already supported everywhere? Because there are a lot of people and projects involved.

It's entirely legitimate to ask, in good faith, why this wasn't done 10, even 20 years ago.

Consider that building a complete FLOSS desktop system is an immense amount of work, and that's what GNOME (even before 2.0) was focused on. Not just "a user interface for Linux", but making the entire stack work for real people. So many improvements in Linux desktop systems came from GNOME developers deciding that the status quo wasn't good enough. We wanted to fix the kernel, device discovery and enablement, dynamic wired and wireless network configuration, rich input devices, accessibility, etc., etc.

Remember, 20 years ago just getting X to work with your bloody monitor to work was enough of a pain.

Then, consider the priorities of the people contributing to the GNOME and GTK projects. Was it more important to break toolkit API/ABI compatibility to let GNOME replace the file chooser, or maintain that compatibility and work on other, arguably more fundamental problems?

Oh, and you know what happens when GTK/GNOME chose to break API/ABI compatibility for 3.x and 4.x? Everyone complained that FLOSS desktop developers can't maintain compatibility and that's the thing holding back "Linux on the desktop".

Anyway, if you're not already turned off by all the abuse that FLOSS desktop developers cop for literally everything they do, from people who don't know any better and people who should know better, I can still recommend it as deeply satisfying work. :-)

Re: File picker meme

#62

Post by Cloudef »

BrightGlow wrote: post #49
Cloudef wrote: post #31

Earlier quoted context omitted.

I was under impression the backend has to implement all of the API to do that. Nice to know it's enough to have dbus service that listens to a single call. I might do this to replace file picker on my machine. It's still baffling however, how fork + exec pipe can't be used for this. Especially considering that under all that dbus cruft the PoC essentially does this: https://github.com/ranchester2/nautilus-as-file-cho…

Using fork and exec with a pipe is not going to work within a sandbox. That "cruft" is necessary for the thing to work...

I get why they invented this for flatpak (Even though it still could be done with processes and namespaces), but my original point was wondering why they did not originally use fork, exec and pipe.

Re: File picker meme

#63

Post by xfer »

dublin wrote: post #32
29athrowaway wrote: post #11

At least we don't have to see ads.

I have never seen an ad in Windows, period. (And for that matter, I've never changed any setting to achieve that. Perhaps this is because as a Surface user, I get Win10 Pro installed by default?) By the way, try using a pen or touch as a meaningfully usable interface on Linux (or Mac)... I'll never buy another computer that doesn't support both rich pen and touch - THAT'S a UI improvement that has changed my life, an…

> try using a pen or touch as a meaningfully usable interface

Have you tried doing that on windows? No a pen is not supposed to be used for scrolling on a pc, it's not a smartphone: https://github.com/TheJoeFin/Windows10-Community/issues/17

I have seen windows ads on pro/enterprise on the lock screen even.

Re: File picker meme

#64

Post by jdub »

JasonFruit wrote: post #29
h2odragon wrote: post #23

What's really important is that the elements of the dialog box all move around every few fears, so no one can get too familiar with it and expect to understand what they see at a glance. The presence of text box in which any text entered does something totally unexpected is at least universal.

Absolutely agree about the bizarre textbox that pops up if I accidentally press a key while the filename box isn't selected... what on Earth is it supposed to be doing? Does anyone want that feature, someone who thinks, "Yes, when I hit a key in a Save dialog, I'd like to have a strangely filtered list of the files that are there already!?"

You may have heard the rumour that GTK/GNOME developers make software for simpleton users that don't exist. But you've just run into a power user feature that you don't understand.

Now, what do you think will happen if the GTK/GNOME developers get rid of that "bizarre textbox" so it doesn't get in your way? Yes, they'll get a torrent of abuse for "removing the last power user feature" or something. :-)

Re: File picker meme

#65

Post by ghostly_s »

dublin wrote: post #20

Gnome's UI really does suck. Windows File Explorer sucks, too, just not nearly as bad. (Though I'd put it FAR ahead of the Mac's counter-intuitive and ill-named Finder.) It's the 21st century - WHY, OH, WHY do we still have file managers that provide NO CLUE as to the size and number of files in a directory? Why are all presentations still list or grid-based? Why does it take so long to find files? Can't we save the…

No idea why this is downvoted, its spot on.

Re: File picker meme

#66

Post by jchw »

Cloudef wrote: post #7
cunidev wrote: post #2

This "meme" is the core of most useless, destroying DE wars in the Linux community. An example of how such a limited case can fuel beliefs of one desktop being "better" than the other, and the latter being something to continuously joke on. The lack of collaboration between desktops is, in my opinion, at the core of the fragmentation that makes Linux desktops still appear so far from their proprietary counterparts. T…

Sometimes collaboration goes nowhere: https://gitlab.gnome.org/GNOME/mutter/-/issues/217

Option A: applications can continue to do what they’ve done for nearly 30 years and rely on system title bars. This will work everywhere — X11 GNOME, KDE, SwayWM, macOS, Windows, BeOS,… except GNOME on Wayland, and it will feel native.

Option B: applications can choose between GTK 3/4 (not exactly a fan favorite) and get native looking title bars only on GNOME (without extra work — also only supports an out-of-date spec for native window frames on Wayland) or they can use libdecoration (or libdecor or whatever) which appears to be persistently not ready for prime time, and will still not look native in most Wayland compositors.

Honest to goodness, apps should just force themselves into X11 mode on GNOME until the compositor is fixed. The CSD initiative is a broken idea.

Re: File picker meme

#69

Post by BrightGlow »

Gualdrapo wrote: post #43
forgotpwd16 wrote: post #6

Earlier quoted context omitted.

This meme isn't a limited case and it's representative of the mindset that GNOME has. Extremely focused in one "vision" disregarding the opinions and issues of users.

Alas it does not happen only on GNOME. For example, mentioning how irrational is that to this day GIMP has no dedicated tool to draw basic geometric shapes (rectangles, ovals) as every other image editor does, even the most basic ones, can get you a lecture about how GIMP is free software, its lack of funding, that (allegedly) those tools are irrelevant and go against their philosophy, downvotes, bans...

I don't get this post. You listed several rational reasons why it has no tool to do that:

>GIMP is free software, its lack of funding, that (allegedly) those tools are irrelevant

If you have a specific feature request, you might consider checking the bug tracker for an existing issue. If there is one, then it's not helpful to mention it any further. The developers already know what the request is. From that point on the only helpful thing you can do is to contribute code, designs, etc towards getting the feature done.

To illustrate, have you ever had somebody sitting behind you while you work who keeps repeatedly saying things like "are you working on that thing for me yet? are you done yet? when will you be done?" until you finish? It's kind of like that. Doing that doesn't help the person go any faster.

Re: File picker meme

#70

Post by BrightGlow »

Cloudef wrote: post #62
BrightGlow wrote: post #49

Earlier quoted context omitted.

Using fork and exec with a pipe is not going to work within a sandbox. That "cruft" is necessary for the thing to work...

I get why they invented this for flatpak (Even though it still could be done with processes and namespaces), but my original point was wondering why they did not originally use fork, exec and pipe.

Because the goal was to make an API that works the same both inside the sandbox and outside the sandbox. Edit: It wouldn't work with just processes and namespaces because you need a way to talk to a resource with a privilege level above the current mount namespace.
Post reply on HN