No, I don't want to add an option for this.

It would make lots of users happy and comes at essentially no maintainance cost (given that type ahead is builtin into tree view). The new search remains at default and is being exposed.

What is the rationale to not accept such an option?

I really don't want to always build gtk myself... What has to happen before this is taken into consideration again?

Given that the reporter included a patch, and that he claims it's not a maintenance burden, it would be nice to hear a bit more from you.

Including a patch is nice, but I still don't want to add an option for this.
I won't repeat well-known arguments about the cost of options here.

I'll repeat my previous question: What has to happen before this is taken into consideration again?

Would it help to have a significant amount of users express that they want this feature back? Shouldn't be too hard to create a poll and ask sites like 'OMG! Ubuntu!' to share it or something like that.

(In reply to Jonas Platte from comment #6)
> I'll repeat my previous question: What has to happen before this is taken
> into consideration again?

A discussion with designers that reverts a significant change in direction for GTK, possibly backed by results of a usability testing.

> Would it help to have a significant amount of users express that they want
> this feature back? Shouldn't be too hard to create a poll and ask sites like
> 'OMG! Ubuntu!' to share it or something like that.

No, polls or surveys will not help your case in any way, shape, or form.

A user study done in a decent way that compares the existing search-as-you-type implementation in the GTK file selector with the previous find-as-you-type implementation would probably help your case. A good starting point is Jim Hall's blog post on how to conduct a small usability test:

  http://opensource-usability.blogspot.co.uk/2014/05/usability-themes-in-open-source-software.html

> A discussion with designers that reverts a significant change in direction for GTK, possibly backed by results of a usability testing.

What are you talking about? This bug report isn't about changing the default behaviour, it's about adding an option!

I happily accept that most people find it easier to work with search-as-you-type, but that doesn't change the fact that it is incredibly frustrating to use for some people. The discussion with designers isn't going to happen, at least on my end, because I don't know a single designer who has any interest in open source software in general, or GNOME specifically.

(In reply to Jonas Platte from comment #8)
> > A discussion with designers that reverts a significant change in direction for GTK, possibly backed by results of a usability testing.
> 
> What are you talking about? This bug report isn't about changing the default
> behaviour, it's about adding an option!

We don't want to add an option that we get to maintain. That's not negotiable.

> The discussion with designers isn't
> going to happen, at least on my end, because I don't know a single designer
> who has any interest in open source software in general, or GNOME
> specifically.

I'm talking about the GNOME design team; and you can perform some usability testing to compare the two solutions by yourself, following the link I gave you in comment 7.

> We don't want to add an option that we get to maintain. That's not negotiable.

What kind of justification is that?? Does that mean you don't want to ever add any features that are optional to GNOME anymore?

> I'm talking about the GNOME design team; and you can perform some usability
> testing to compare the two solutions by yourself, following the link I gave
> you in comment 7.

You seem to want me (or us, the ones who want this feature) to prove to you that it would work better for everyone, when that's not what we're claiming at all. I even think that search-as-you-type does make more sense for most users. What I am asking for is a way of having an optional feature – that wouldn't be good as a default – considered to be included in gtk.

As a side note, the links to the actual document on that blog post from comment 7 result in 404s.

Bugzilla is not a forum. If you want to ask questions, either use gtk-devel-list@gnome.org or join the #gtk+ channel on irc.gnome.org.

This is going to be my last comment in this bug report.

(In reply to Jonas Platte from comment #10)
> > We don't want to add an option that we get to maintain. That's not negotiable.
> 
> What kind of justification is that??

We replaced a feature with another feature. We don't add options to switch between the two because we see the latter as a superior implementation. The only way to get the previous feature is to replace the new one with the old one, because they directly conflict in scope, implementation, and use.

The only way to get the old feature back is to convince designers and maintainers of the project you're using that the replacement is bad, with numbers or user testing that backs your claims.

> > I'm talking about the GNOME design team; and you can perform some usability
> > testing to compare the two solutions by yourself, following the link I gave
> > you in comment 7.
> 
> You seem to want me (or us, the ones who want this feature) to prove to you
> that it would work better for everyone, when that's not what we're claiming
> at all. I even think that search-as-you-type does make more sense for most
> users. What I am asking for is a way of having an optional feature – that
> wouldn't be good as a default – considered to be included in gtk.

And you've been told, multiple times now, that since the two features collide, either one has to go.

We don't add random options to switch between competing features, and each option we do add is constantly evaluated against the larger scope of the project, our ability to test and track regressions, and the resources available. For more information on the cost of preferences, please read:

  http://ometer.com/preferences.html

> As a side note, the links to the actual document on that blog post from
> comment 7 result in 404s.

Thanks; I'll inform the author of the blog post.

> 
> A discussion with designers that reverts a significant change in direction for
> GTK, possibly backed by results of a usability testing.

I would be interested in the formal usability testing that that lead the the change to the current behaviour in the first place.

I'm interested because for me the new behaviour is immensely less usable and still not bug free.

TBH: I doubt usability testing is a requirement, depending on who makes the change. Or maybe it is used as an excuse to reject community contributions.

I don't understand why you want to stop discussion this as we get to the core of the problem, but I'll at least express my opinion at this point:

> We replaced a feature with another feature. We don't add options to switch
> between the two because we see the latter as a superior implementation. The
> only way to get the previous feature is to replace the new one with the old
> one, because they directly conflict in scope, implementation, and use.

> And you've been told, multiple times now, that since the two features
> collide, either one has to go.

Actually, this is the first time I explicitly read that you have a problem with this being an option because it would conflict with the other behaviour. Call me stupid, but before, it actually sounded to me like you were against optional features in general. I still don't fully understand this reasoning though, as there are other behaviour-changing options that have a much bigger impact, for example the natural scrolling option for touchpads.

> The only way to get the old feature back is to convince designers and
> maintainers of the project you're using that the replacement is bad, with
> numbers or user testing that backs your claims.

Alright, I will see what the people on the #gnome-design channels will say about this.

> We don't add random options to switch between competing features, and each
> option we do add is constantly evaluated against the larger scope of the
> project, our ability to test and track regressions, and the resources
> available. For more information on the cost of preferences, please read:
> 
>   http://ometer.com/preferences.html

I am not arguing in favor or just adding options for everything; I'm aware that not all possible preferences are reasonable to have. I guess a lot of my frustration on this bug report just comes from the fact that I was expecting to have a chance to explain how the new feature is problematic for me, but apparently this is not the place to discuss with the people who should hear about that, namely the designers.

Insofar, maybe the reference to this bugzilla on the 'Design' wiki page [1] under 'Providing Feedback and Design Ideas' should be removed or changed to reference a special 'Product' to file design bugs under.

[1]: https://wiki.gnome.org/Design#Providing_Feedback_and_Design_Ideas

I think people in this bug have become far too involved in this discussion.

You should go back and try the current behavior with GTK+ master. I'd be interested in what the remaining complaints with the current search behavior are. We have tried to address most of the complaints that people have brought up over the past year or so:

- We do show hits from the currently loaded directory, _right away_

- We sort hits from the currently loaded directory at the top

- We select the first hit so just hitting Enter works

At this point, I believe the only remaining complaint is "but its not typeahead!!!".

I've expressed my concerns here https://mail.gnome.org/archives/gtk-devel-list/2015-August/msg00047.html, unfortunately the mail was completely ignored.

Let me paste:
> To summarize why the new search isn't a viable replacement:
> 1) Search results appear with delay compared to type-ahead find (though not large)
> 2) I can't just open/select the first match with enter because it's not highlighted
> 3) the search results mix files and directories even if the original directory view has directories sorted before files and regardless of the context-menu->show dirs before files checkbox (is this a bug?)
> 4) It does substring search so files/dirs that end with my search pattern are listed as well (sometimes even before those that I want to select in the first place)
> 6) The file view radically changes upon search even if my intend is to simply select an item from the unchanged view
> 6) It feels alien compared to previous and Windows experience (I still use Windows from time to time). 
> 
> 3 and 4 are most annoying, I could perhaps live with it if those where fixed. However, since type-ahead-find is still built into the GtkTreeView widget enabling it for the file chooser requires essentially no additional code so IMO the setting to re-enable it for those who favor it makes sense and comes at no cost. 

So I guess 1) and 2) are fixed. Thanks for that. But 3 and 4 remains. These are my deal breakers which make search in open file dialogs a lot less accurate than the traditional type-ahead. As a consequence I need a lot more time (and often many tries) to navigate. For me, items where the string matches the start (not any substring) of the file name should be sorted first, and directories separated from files (depending on the existing "Show directories before files" check box).

In fact, I've been using the current behaviour for some months now (I switched back to the standard Arch package because it's a lot of hassle to maintain a patched GTK and still get updates). In that time I found other awkwardnesses with search-as-you-type which aren't on the list I posted in August:  I find cancelling the search is awkward: 1) deleting the search term does nothing, 2) CTRL+Backspace doesn't work most of the time, 3) pressing escape onces does nothing but pressing it another time clears the search.

Even after this long time, I just can't adapt to the new method, to the point that I actually prefer GTK2 programs these days (to be fair, GTK2 has some other favorable features compared to GTK3, not just this one).

Thankyou Matthias for clarifying where things are heading.

As it turns out I do now remember seeing this mentioned on your blog [1]. But I'm running Fedora 23, and it's still only GNOME 3.16... so yet to actually see the new behaviour in action.

I guess a big problem here is that people really shouldn't be needing to follow developers' blogs to know where things are headed. Moreover, although the GNOME website has a lot of stuff on design [2], it's really difficult to work out which bits are just ideas, which bits are actual planned goals, which bits have been obsoleted, and so on.

Anyway, now that I've had a closer look, it does seem as if the mockups on file selection [3] mention all the behaviour you've just described (though you have to view the images directly in order to read the text!). If only we'd been linked to this right at the top of this bug.

[1] https://blogs.gnome.org/mclasen/2015/07/30/1429/
[2] https://wiki.gnome.org/Design/
[3] https://wiki.gnome.org/Design/OS/FileSelection

> You should go back and try the current behavior with GTK+ master. I'd be
> interested in what the remaining complaints with the current search behavior
> are. We have tried to address most of the complaints that people have brought
> up over the past year or so:
>
> - We do show hits from the currently loaded directory, _right away_
>
> - We sort hits from the currently loaded directory at the top
>
> - We select the first hit so just hitting Enter works

Okay, I don't know if anything has changed on master since 3.18.7, but at least the second and third statement apply here. With the first one I'm not sure. The search seems to only start a short moment after I stopped typing, which makes a lot of sense for a search; it doesn't make sense for selecting an element from a list though. So currently, I have to wait a brief moment before pressing enter, otherwise I get the search results instead of opening the file / going into the directory. If this is somehow fixed in GNOME master and will be released in GNOME 3.20, I'll be happy to use gtk without the typeahead patch from then on, but currently I'm still annoyed by search-as-you-type.

So, I tried out the git version now. It doesn't look like the problem I mentioned in my last comment is fixed there. I discovered another problem though which applies to both 3.18 and the git master: The search doesn't consider prefixes in the ordering. What I mean by that is that when I have to files or folders "abc" and "bcd" and my search term is "bc", the first result will be abc, because it's the lexicographically smaller one. I would expect bcd to be the first result though, as I the first few characters of its name like I would with typeahead.

This also means that if the name of a file or folder is completely contained in the name of another file or folder, and that other file or folders name happens to be lexicographically smaller than the first ones name, it's impossible to select the first one without using either the arrow keys or the mouse.

(In reply to Matthias Clasen from comment #14)
> I think people in this bug have become far too involved in this discussion.
> > 
> At this point, I believe the only remaining complaint is "but its not
> typeahead!!!".

So we have raised numerious concerns with the current state. What's your response to these concerns?

I don't get what's wrong with typeahead.  Why shouldn't it be an option that can be toggled in dconf or a config file somewhere?  Or at the VERY VERY least a compile-/config-time option?