4 ms·

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 littl

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

zxzax 5y ago
>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.
- rstat1 5y ago
  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.
  - zxzax 5y ago
    >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.
    - jstimpfle 5y ago
      > 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.

zxzax 5y ago

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

rstat1 5y ago
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.
- zxzax 5y ago
  >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.
  - jstimpfle 5y ago
    > 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.