Comment by traverseda | Hacker News Reader

Comment by traverseda | Hacker News Reader

Parent Full thread

As a programmer Gnome has really damaged their relationship with a lot of developers.

For example take a look here: https://trac.transmissionbt.com/ticket/3685#no1

>I guess you have to decide if you are a GNOME app, an Ubuntu app, or an XFCE app unfortunately. I'm sorry that this is the case but it wasn't GNOME's fault that Ubuntu has started this fork. And I have no idea what XFCE is or does sorry.

Gnome kind of goes off and does it's own thing without thinking about or cooperating with other open source developers. [Here's](https://gitlab.gnome.org/GNOME/mutter/-/issues/217) an example where they make a technical decisions that massively inconveniences a bunch of well known open source projects like GLFW and SDL (low-level cross-platform GUI toolkits).

Gnome are not good citizens of the open source commons, they do things that make it much harder to create cross-platform/cross-DE apps. GTK used to be fairly vendor neutral, it was the "GIMP ToolKit", not the Gnome toolkit. It worked with any desktop environment you chose to use. Since then they've been making the toolkit much more dependent on Gnome specific features and actively been making the lives of everyone else more difficult.

Also there are a lot of controversial decisions that make developers lives annoying, like [refusing to implement classic typeahead](https://gitlab.gnome.org/GNOME/nautilus/-/issues/244) instead relying on their search daemon which is really annoying for a lot of developers, and of course makes running a GTK app in a non-gnome desktop much worse. There are a few outstanding issues that make it annoying for developers to work with file paths under Gnome.

So yeah, they've burnt a lot of developer good will and seem intent on continuing that trend. LXDE even switched to QT instead. Really made it so that the linux desktop is less of a stable/reliable thing to develop for.

---

https://blogs.gnome.org/tbernard/2019/12/04/there-is-no-linu...

By refusing to cooperate with other open source projects they're really making it harder for open source developers to get things done and make new apps. Instead of having a common platform we now have gnome and everyone else, and there really are a lot of very obvious examples of that happening over the years.

Your first link is an issue that was posted over 10 years ago and was long resolved in other areas. It's not an illustrative example. I really wish people would stop trying to revive these ancient flamewars without acknowledging the current state of things (not saying this is your fault, but a little diligence always helps).

The second two links you're posting are again, the exception, not the rule. The vast majority of patches are accepted, you just happened to stumble across two of the contentious ones that got a big outrage response on reddit. Please go look at the other thousands of issues and MRs against GTK if you don't believe me, it's not just GNOME people filing those.

I would say I thoroughly agree with the last article you posted. There has never been a "Linux platform." It was always Motif versus KDE versus GNOME versus Enlightenment versus all the rest. Historically they only cooperated with each other on certain things. If none of them refused to cooperate, we would still probably be using Motif. We can come up with various reasons for why this fragmentation happened but placing all the blame for that on GNOME for going its on way doesn't make many sense when this fragmentation always existed.

> It's not an illustrative example.

What I'm describing is a cultural problem. If you don't think that link is illustrative than you don't understand what it is I'm trying to illustrate.

Again this particular cultural problem was resolved a long time. Ubuntu and XFCE and GNOME have since all aligned on this matter. I see what you are trying to illustrate, maybe it was true 10 years ago, but it's not now. Cultures can change you know.

As someone who has to occasionally work on a Gnome desktop, I can confirm that they still haven't fixed type ahead in Nautilus. Another point is that their Alt-Tab has a strange auto-grouping behaviour that totally breaks my workflow. (I have multiple terminal windows open and switching between them is a pain, it has to be seen to be believed).

Two big annoyances, and reading that type-ahead thread quoted above is quite an experience. Being in my 30s, it's been a long time I've felt such an enormous disgust at the amount of neglect and arrogance that is being displayed there.

And I strongly disagree with that sentiment "it's ours, go make your own if you don't like it". Point is, I do not want to use their crappy product but I have to, due to political forces that extend from Red Hat to what my employer has installed on that computer in the lab that I have to deploy and test my software on.

If I had a choice, I would prefer to install there my simple arcane plain window manager, xterm (fast and crisp), and just enough junk so I can do my work. My Thinkpad X220 with this setup is actually pleasant to use and has required basically 0 maintenance in the last 6 years.

>it's been a long time I've felt such an enormous disgust at the amount of neglect and arrogance that is being displayed there.

Please do not assume bad faith. Type-ahead has some confusing usability issues, such as that it only matches against the beginning of the filename, which from my reading is why it probably will not be brought back. The way forward is to help get the current solution up to par. I feel your pain, but giving up and reverting to old type-ahead behavior will only ensure that the issue never gets a proper fix. It's very hard to have a conversation about this when people assert that the real cultural problem is that a particular feature they want isn't implemented.

>Another point is that their Alt-Tab has a strange auto-grouping behaviour that totally breaks my workflow.

Has this been reported?

I don't assume bad faith, following Hanlon's razor it's obviously stupidity and probably a culture of arrogance engrained into a larger group (I know very little about the organization there, but there has been a lot of heated debate for years about other groups connected to redhat).

How can they otherwise ignore such an obvious, massive load of complaints with dismissive and side-stepping comments?

> Type-ahead has some confusing usability issues, such as that it only matches against the beginning of the filename

Please, explain to me, what exactly is confusing about that? That it matches precisely against the beginning of the filename?

It's the exact polar opposite of confusing, and furthermore it's extremely useful in my (and many others') workflow for navigating large directory trees where I know which path I want to take in advance (obviously this is a frequent situation for all the things I'm currently working on).

And I am convinced this is not a coincidence or a pecularity of my workflow, precisely because the behaviour of type ahead is simple and predictable and also matches how humans tend to remember names, which is most likely by their initial letters.

This old and proven workflow reduces a lot of stress coming from increased visual-motoric interaction, compared to the search behaviour in Nautilus where the screen gets updated in unpredictable ways (both in terms of the files that are displayed, and also in the time lag to when they are displayed and interactable). We're talking multiple or many seconds of wait and stress that this behaviour can cause, even on beefy machines. Noone working in UI would disagree that operations should aim to take less than 100ms.

(by the way I don't dispute that more involved navigation facilities are useful sometimes, for example I like to use glob-patterns that start with a * or something from time to time. However prefix search is clearly the most accurate and fastest tool for like 90% of my navigation needs).

>How can they otherwise ignore such an obvious, massive load of complaints with such disrespectful and dismissive comments? [...] We're talking multiple or many seconds of wait and stress that this behaviour can cause, even on beefy machines.

I don't think the complaints were ignored, multiple other tickets with concrete work items were opened in response to the complaints. There is a ticket open to improve the speed. The particular suggestion for a fix was dismissed, but that's a separate thing.

>Please, explain to me, what exactly is confusing about that?

I personally find it confusing, in large folders I often don't remember the exact name. I don't think this behavior is particularly bad if the user knows what is going on, but going back to making it the default and de-prioritizing search can make it hard to find some files.

You can keep the type-ahead functionality while also implementing proper full search like every other OS available does. It doesn't need to be a one or the other type deal.

File Explorer in the last 4 major Windows releases has a search box in the top right of the window, while also supporting a type-ahead search as well. There's no reason why GNOME can't also do that.

I don't think you'll ever be able to improve the speed of a full search to a point that it'll match the performance of a type-ahead style search.

>It doesn't need to be a one or the other type deal.

Sadly it does. Search is currently the default. If you bring back type-ahead, that will de-prioritize search. Nautilus could copy the Windows approach but that would also bring along with it all the issues of the Windows approach, where there are two similar options with subtlely different behavior of how they match against file names, with no clear explanation to the user why this is or why some files are accessible in one way but not the other. You and I may be familiar with the approach because we're used to it but other users might not. I've seen some users that have been using Windows for decades and still they have no idea what type-ahead is because they never even thought to type into the file manager.

>I don't think you'll ever be able to improve the speed of a full search to a point that it'll match the performance of a type-ahead style search.

Why not? I would think search would actually be faster, because that only has to show a few relevant search results, whereas type-ahead has to keep scrolling the view around and reflowing the whole folder.

> I've seen some users that have been using Windows for decades and still they have no idea what type-ahead is because they never even thought to type into the file manager.

Haven't thought of typing into the file manager, like most non-programmers probably. And how does that support your argument that re-instroducing Type Ahead would de-prioritize search for them?

> I would think search would actually be faster, because that only has to show a few relevant search results, whereas type-ahead has to keep scrolling the view around and reflowing the whole folder.

Search could be faster if reading the directory was the FAST operation and displaying was the SLOW operation.

You can cook up situations where that is the case, like when the application has the directory cached in memory and / or the directory has (recursively) very few entries AND the display is actually on the other end of a remote desktop connection in the Siberian Sea so that it might matter whether you display 1 or 3 folder icons.

In more realistic cases, like where you have 10GB/s of memory access performance and a fast link to the GPU/display, but file systems that are still comparatively slow (especially with regards to filepath lookup, especially for directory trees that are routinely gigabytes in size / routinely have 1000s of entries in 100s of subdirectories), that will never be the case, not by a factor of 10s of 1000s.

If you don't preload the folder contents and index it then type-ahead will also be arbitrarily slow there too. I don't know of any Linux filesystem that stores the files sorted and indexed on disk.

>And how does that support your argument that re-instroducing Type Ahead would de-prioritize search for them?

The idea I got from reading the GNOME HIG is that if users accidentally type into the window, the behavior should be consistent and predictable with what the user was really trying to do (search). Doing a strange and inconsistent matching behavior that is not available through any other means and is essentially hidden functionality is only going to cause confusion.

But why would you rely on the filesystem to implement Type-Ahead? The File Manager just goes through that little list of files that it has already cached because it is displaying them anyway.

And it just goes through the list linearly, starting from the currently highlighted item, stopping at the first match.

It's a miniscule operation.

--

Speaking practically, have you ever experienced any file manager that has type-ahead (like most do) and the type ahead was not blazingly fast?

> The idea I got from reading the GNOME HIG is that if users accidentally type into the window, the behavior should be consistent and predictable with what the user was really trying to do (search). Doing a strange and inconsistent matching behavior that is not available through any other means and is essentially hidden functionality is only going to cause confusion.

If you're refusing to see that they achieved just the opposite and broke a totally sane implementation that was super predictable for any user that actually cared about their workflow, you can't be helped.

Until global file indexing became a thing built into operating systems, every file manager was slow to open and sort directories with a lot of files. At least that was my experience. An index is still needed to do type-ahead, at minimum you'd need to build a prefix tree. You can't just load the list of files and be done; linear search will cause the same arbitrary slowness. Imagine typing an 'a' when on disk the all the 'a' files happen to be stored at the end of the directory. You would have to rescan the whole list every time you type another letter.

>you can't be helped

This is not the way to have a constructive conversation, please stop. I gave an example of how it's confusing and not predictable for some, let's discuss ways we can make it more predictable.

See, you just iterate the list or array where you store the list items that you're pushing to the screen anyway. There is nothing at all that you need to add in terms of data structure. No index whatsoever.

> linear search will cause the same arbitrary slowness.

Let's see. My Thinkpad x220, which was built almost 10 years ago, can easily scan through 10 Gigabytes of memory per second. If we assume that visiting each list item causes a cache miss though (which is pessimistic), then (assuming a cache miss costs 100 nanoseconds) maybe we can visit roughly 10 million directory entries with the worst possible, dumb, serial implementation. Let's say we want to ensure a reasonable target of not wasting more than 1 millisecond for the search, we can still Type-Ahead through directories containing 10000 entries with incredible performance (1ms latency).

However, if the directory contents are stored only in a slightly reasonable structure (say, the developer spent the slightest thought at it, like caching the entries in a list of array chunks or so), then, I don't know, it might be closer to 100K entries per 1ms or even approach 1 million entries per 1ms with a little optimization.

It's not a problem at all, it's less than a piece of cake.

If you're set on linear search then you would see the same performance for a simple search box too, I don't see how type-ahead changes it. For big folders you will still need an index, imagine now you sorted the list by reverse alphabetical, typing an 'a' is still going to be slow when you're at the top.

Again, the point is that type-ahead is an operation on the directory entries that are cached in the file manager's memory. It does not touch the file system at all.

That's why it is so fast in practice, it's instantaneous (as far as screen refreshs go) on every file manager I've ever used.

Recursive search however, does have to touch the filesystem, and does have to touch it massively for directories that contain thousands of subdirectories. That's what a "search" is, the user expects the search results to be fresh from the file system, not just scraped from a cache internal to the File Manager.

That's why recursive search is so disturbingly slow, to the point where it routinely takes seconds, or could even minutes depending on the setup (spinning drive + bad filesystem + large directory tree...).

And that is why Nautilus is basically unusable for me and a lot of other people.

By the way, there are other semantical problems with search vs Type-Ahead. For example, I cannot type a prefix in the current directory to see whether there is a file with that prefix in the current directory. Nautilus' recursive search will just pull up a completely unrelated and unexpected file from somewhere in this tree.

That means, that if I mistype, I don't get any reasonable feedback from Nautilus, but instead get a warm "thank you" and a huge diskload. It's about as depressing as browsing some websites that bombard you with ads and never show the contents you searched for.

> Again, the point is that type-ahead is an operation on the directory entries that are cached in the file manager's memory. It does not touch the file system at all.

So would a simple search in that folder? I don't see what is special about type-ahead here. I'm not talking about recursive search, that can already be disabled in Nautilus if you don't want it. I think this another reason is why it's bad that people get so outraged about this, a lot of the anger is directed at recursive search when really the solution there is to just fix or disable recursive search. Bringing back type-ahead is not the only way to deal with the problem. Another option would be to speed up recursive search so that it uses your suggestion first to do a fast search and quickly display results from the current folder before recursing, that would be the best of both worlds.

>By the way, there are other semantical problems with search vs Type-Ahead. For example, I cannot type a prefix in the current directory to see whether there is a file with that prefix in the current directory.

That could also be solved with an intentional search option to search by prefix, maybe with a button and bound to a certain key that makes it obvious and not confusing what's happening. I'm not saying it's bad to search by prefix.

I don't know, I haven't tested if that is fast, but I'm assuming it does hit the disk again (since they refused to add another "feature", if "Type Ahead" even deserves that name).

Even it was fast, which I assume it is not really, I would prefer to have usable defaults without having to hunt for an obscure setting on every computer I happen to walk to, which is usually not even my own.

And as many other commenters on that gitlab.gnome thread described, I would much prefer to not to have the list filtered.

And also, I would strongly prefer not to have to disable/toggle this setting again to actually do a recursive search.

I just don't understand how it can be so hard to communicate why the existing status was so much better. And why the current status is unusable. I guess only people who never actually used that earlier feature don't understand.

But I will try that setting out next time... I hope then, that they fixed their stupid settings manager, which, at least some years ago, was some daemon that wrote to a binary database, and that frequently crashed, and then forgot some of its settings.

> That could also be solved with an intentional search option to search by prefix, maybe bound to a certain key that makes it obvious and not confusing what's happening.

The current search does just that, it's extremely confusing. It doesn't have a real search box, it is triggered as soon as you type the first key (which might be accidental), at which point it switches to a different UI state - and it's "flickering", it takes ages for the process to complete, and what your following key presses do within that timespan is very much dependent on the timing of the updates from Nautilus...

I don't understand why you keep defending it. It's a huge disaster on all fronts. It would be soooo much better if they would just protect that messy imperfect search thing by a Ctrl+F combo, and otherwise do the simple Type-Ahead thing. It might be only like 20 lines of code to change it....

At least from my read of the gitlab issues, I don't think anyone is saying that the current solution doesn't have problems. The idea is to get those problems fixed instead of ditching the current solution entirely, or making it an optional toggle (which would make even more likely that nobody fixes the issues). For me personally, I did use type-ahead but my feeling is that a really good and fast search would make it obsolete.

Win95 and Win98 had super fast file managers.

Hell, the whole 9x era of Windows would run laps around all these "modern" desktops.

I'd love to see the source code to the Win95 and Win98 file managers, maybe we can copy some of the performance tricks.

The "trick" is to just run a loop over a list stored in RAM.

That seems to be over simplifying, every database is "just running a loop over a list stored in RAM." The challenge is in how you build that list, and then with a GUI the challenge becomes how to display it. Win95 had to run in very memory constrained environments compared to today so I'd imagine there is some special considerations there.

I don't find there is a lot that could make sense to do. I believe computers running Win95 had like 16-128MB of RAM, it wouldn't be too wasteful for a file manager to store, say, 32-64K worth of cached file entries uncompressed in RAM. That could allow for maybe 1024 file entries (depending on the attributes that should be cached for each entry - more if we're really just storing a list of zero-terminated strings and maybe directory bits), which would already cover almost all realistic use cases at the time.

So it's literally a loop over that in-RAM cache in most cases.

It seems like e.g. FAT32 allowed for theoretically 64K entries per directory, but I find it unlikely that most programs would bother to optimize for that. One could just punt and allocate more memory dynamically in those cases until there is a Out-of-memory situation.

Or one could page in the directory entries chunk by chunk (so, maybe 64 chunks max) on each update which would considerably slow down some operations of the program (such as scrolling, sorting, type-ahead, when any of those cross a chunk boundary), but still be acceptable as a rare occurrence.

Or, if one specifically wanted to optimize for something like scrolling or type ahead, which are simple "linear movements", one could just keep this linear list (sorted according to user preferences / filters) in a cache file on disk. Streaming that in chunk-by-chunk is very fast as well, since you only need one disk access to get at the next chunk.

I figure that would be way overkill for most practical requirements, but it still wouldn't be a lot of work to implement.

I don't even use Gnome, but the behavior in the gtk open and save dialogs changed in the same way a few years ago, so I'm going to assume it's the same issue:

I hate hate hate the new search behavior, and would go back to the old ("type-ahead") behavior in a second if there was a setting I could toggle.

I don't think it's "bad faith", I think it's just weird group-think and having things other than the users as priorities. The amount of condescension and misplaced confidence displayed in that thread is impressive. If you (or anyone reading this) is affiliated with the Gnome project, please reconsider how you handle and incorporate user feedback into your products.

>The amount of condescension and misplaced confidence displayed in that thread is impressive.

I would say that assuming condescension is assuming bad faith. If there is a comment that is truly rude and dismissive, it should be reported as a code of conduct violation. Otherwise, please don't assume the response is trying to put you down because it's disagreeing on technical grounds. Any bug report has to go through technical review, and the developers will almost always have more information about the code than the reporter.

>I hate hate hate the new search behavior, and would go back to the old ("type-ahead") behavior in a second if there was a setting I could toggle.

To give another opinion, I personally don't feel the same way about this, and I don't think it would be much benefit for there to be a setting.

>If you (or anyone reading this) is affiliated with the Gnome project, please reconsider how you handle and incorporate user feedback into your products.

I'm not affiliated, I'm just expressing my personal opinion on this, as you are. Not all user feedback is created equal. Sometimes, the developer must firmly say no because something isn't technically viable. Users don't decide what is technically viable or not, only the developer tasked with writing the code can make that decision. Sometimes, the developer is faced with a choice between competing requirements, and it's not possible to fulfill both technically. Once the decision has been firmly made, there's little purpose to accepting further feedback after that. Committing to a solution means the developer has to accept the effects of it, losing users is always a possible effect, but so is users changing their mind.

You're right, condescension is the wrong word. I apologize.

I do think it's misplaced confidence, though. Look at the upvotes/downvotes on the comments in the type-ahead issue thread. What the gnome developers are saying is clearly unpopular, and what the person who filed the issue and others are saying is clearly popular. Yes, of course, that's not a representative sample of all users. But was there ever a representative sample taken? What gives them the confidence to declare that the search behavior is superior, and so far superior that it must completely subsume the old behavior without even an option? No evidence is presented in that thread. They only say "This was a decision made a while ago, because people believed that searching can provide the same functionality." On what evidence is that belief based on, and what would be sufficient to overturn it? How large of a user outcry would there need to be? If this were my software and 59 people thought that one of my decisions was wrong (the largest vote count in that thread), I would start to strongly question my assumptions. No such questioning appears to be happening here.

To respond to your specific replies:

> technical review

This is a design question, not a bug. It's not about the code. The complaint is obviously valid.

> I don't think it would be much benefit for there to be a setting

Of course, anyone who will keep a setting in one position doesn't see value in there being a setting. I don't either: I'd be even happier if it always worked the old way, instead of a setting. But that's what settings are for, where there's multiple valid ways for something to work and not everyone agrees.

> technically viable

The old behavior is obviously technically viable, it worked that way for many years. So again, that's irrelevant, unless you're arguing that a setting to switch the behavior is too technically difficult, which seems implausible.

> Once the decision has been firmly made, there's little purpose to accepting further feedback after that.

Of course there is! If you don't accept further feedback, how will you ever know if your decision was wrong? This is the crux of it: a decision was "firmly" made by some developer based on who-knows-what criteria, and then no feedback is accepted, no matter how loud.

> losing users

I'm not a gnome user and never will be, but I'm forced to accept these decisions because they affect the gtk file dialogs also, and I can't exactly quit every piece of software that uses gtk.

> Your first link is an issue that was posted over 10 years ago and was long resolved in other area

this issue https://gitlab.gnome.org/GNOME/mutter/-/issues/217 is proof that it hasn't been resolved at all. Just reading GNOME maintainer's entitled comments ("If individual applications rely on non-standard behavior from compositors, those applications should get fixed. ", "I mean Qt should use GTK to draw decoration.") make my blood boil

I don't see how that is entitled. If you have technical arguments for why you disagree then I'd love to discuss that. Qt linking against GTK is not such a strange idea either, I believe at one point there was GTK theme engine for Qt that used GTK drawing functions to draw Qt widgets.

Reply on news.ycombinator.com