GNOME Bugzilla – Bug 169296
Let typeahead find use auto completion
Last modified: 2015-02-16 14:14:22 UTC
The current typeahead find is really great but can be improved I think by using predictive text. Let me give an example. I'm hacking on nautilus. Most of the files have a nautilus- prefix. If I now use the typeahead find of the file selector I first have to type nautilus- until the type ahead find starts to be useful. What would be handy if gtktreeview would notice that after I type for example nau that the only possible file is a nautilus- file and that then after the cursor tilus- would appear. Open Location of nautilus for example has that behavior
Created attachment 39330 [details] [review] Patch which does the auto completion. This patch basically works, but still is not in commitable state. I just like to have some feedback on this patch/feature before I put more time into it. I struggle basically with how the autocompletion should work. typeahead find is case insensitive. My current patch is case sensitive because I think it would look very funny if the text in the search entry box would be a mix of cases. E.g. you would have an item in the tree view that is called "Bruce Springsteen" If you type a "b" the selection would immediately to Bruce Springsteen if that was the only entry that started with a b or B the completion text in the current implementation will not complete the the 'b' because a 'b' does not match a 'B'. What should appear if we would go for the case insensitive approach? "bruce Springsteen", "bruce springsteen" or should I change the case of 'b' to 'B'. What would happen if I have 'bruce cockburn' and 'Bruce Springsteen' in the same treeview? If we can solve this I'd still like to do the following things with the patch * Adhere completely to the coding style of GTK * Write a gtk_tree_view_next_iter helper function so both gtk_tree_view_search_iter and gtk_tree_view_search_completion_text can use that code i.s.o. the copy paste I performed now.
On gtk-devel-list, it was mentioned that much of the code came from nautilus. This is a problem, since nautilus is GPL not LGPL. It would be necessary to contact the original copyright holder for relicensing.
Original copyright holder of the functions I copied * set_position_and_selection_to_end * position_and_selection_are_at_end * get_editable_number_of_chars * entry_would_have_inserted_characters is Darin Adler but I'm having difficulties finding his current email address. Maybe you know it? The functions are pretty simplistic so we could also easily rewrite them. Can you also give a comment about the case sensitivity and the feature in general? Thanks Jaap
Forgot to mention that the code of nautilus I'm using got added in nautilus-location-bar.c 1.23 and 1.63
OK, Darin Adler gave his permission On Apr 29, 2005, at 2:27 PM, Jaap Haitsma wrote: > I thought it would be pretty cool to let the typeahead find feature of GtkTreeView use the same completion mechanism as the nautilus location bar. So I wrote a patch for it [1] using code from nautilus > > However GTK has a LGPL license and nautilus a GPL license, so I need permission of the author of that piece. If I check CVS the original author seems to be Darin Adler. However I can't find a valid email address of him to ask him for permission. Does anybody have his email address? My email address is darin@bentspoon.com. What you describe sounds fine with me. It's fine to put that code inside Gtk under LGPL. -- Darin Mail is archived at http://mail.gnome.org/archives/nautilus-list/2005-April/msg00239.html
I think this is nice to get in, but I am not sure whether we want this enabled by default or whether we should make it possible to turn this on/off.
When I proposed this on the gtk mailing list there was somebody who proposed to use a kind of firefox search. So that you that it will try to match anywhere. So if you have Bruce Springsteen Bruce Cockburn Bruce Lee and you type "sp" Bruce Springsteen will be selected. The selection then should be made visible by the normal selection (in my case blue, I use clearlooks) and I guess the letters Sp then could be green or so. My knowledge of GTK is actually not that good. With some help though I might be able to implement it.
Created attachment 47958 [details] screenshot showing the idea of using firefox search If we would use firefox search we also do not have any issues with case sensitivity. Because it can just be case insensitive
If we want to highlight stuff, like in firefox, we would have to modify cell renderers. For the text renderer, this is possible. But the search code in treeview searches in model data, so you can search on a column in the model which contains text, but is displayed as pixbufs. How would you highlight something in the pixbuf then? I don't think making this look like firefox is a good idea. So now we can't really highlight things in the cells, I don't think it's a good idea to have the search match anywhere (the views and columns *could* be really wide). I think keeping the search simple is the best thing to do, I would go for a left-to-right search (or vice versa of course) like it is now, with a small API addition to autocomplete matching prefixes.
Kristian, I'm afraid I don't understand your arguments. I would say that if you display everything a pixbufs, find as you type should be disabled, because as a user I don't have a clue what I should type. So I think find as you type should be disabled for these kind of columns. The problem I have with autocomplete is mostly aestetically because you don't know if you it case insensitive the completion might look funny, i.e. a strange mix of capital and non capital letters. An option of course might be to you just change the case of what is being typed depending on the selection. On of the arguments in favour of using the firefox approach was that often you only remember a part of the filename or what ever you are looking for and if that is not the first part then the current find as you type does not help. The firefox find as you type then works well. It's not that I'm against the auto completion (I came up with the current patch) but I got convinced that the firefox find as you type is more efficient. Furthermore it solves the issue of case sensitivity. Another idea is maybe that the API gets expanded so you can select which kind of search you want to use.
I am not saying that you should have columns with pixbufs in your program with search enabled on those; I was just giving an example. The point I was trying to make is that there is more than just cell renderers with text where treeview search can be used. The progress cell renderer might be a better example, and I don't know what people are going to come up with in the future. If we are going to force search highlighting on people, highlighting should be possible to implement for more than just the text renderer. I do not intend to expand the cell renderer interface with highlighting just for the text renderer, nor do I intend to start special casing text renderers in the treeview search code.
I suppose there are two different issues: i) find a substring ii) highlight that substring when found i) is slightly tricky because often you will want to search on a beginstring first and a substring only when no beginstring matches. But if this is sorted out, then ii) is a nice but not required bonus.
The two places where I use "find as you type" from gtktreeview 1. File Open Dialog 2. Rhythmbox These are usually pretty short texts where you are searching on. Are there applications where there are large lines of text in a gtktreeview where you would use find as you type? I'm confused why users would like to do text searching on something which is not a text renderer. The other renderers that exist according to the gtk documentation: progress, toggle and pixbuf. Can somebody give an example of a GNOME application where this can be useful and obvious to a user?
Right now, I don't know of any application with large lines of text in a treeview. People might want to do text searching on some other renderer than a text renderer. Note that GTK+ comes with some 'standard' renderers, but people can write their own. And we have to support it. Also, it's not only a question where things can be useful right now, but also where things can be useful in the future. GtkTreeView is an incredible flexible widget, and I want to keep it that way. I am not going to give that up for this particular feature.
OK, I trust you on this one ;-) So how do we proceed with the current patch? The current patch is case-sensitive and that is not what we might want.
after 10 years of no activity, I don' think this is going to happen