GNOME Bugzilla – Bug 707608
Remove [Current] [All books] filtering buttons, always search in all
Last modified: 2015-02-16 08:39:22 UTC
The [Current][All books] buttons to filter the search hitlist are not optimal; several bugs have been reported about its location and how much space they take (bug 707380, bug 705373 and some other one I cannot find). I'm not sure if anyone really uses the 'Search only in Current book' functionality; I personally don't. And designers have also complained about it in the past. So I'm opening here the discussion as to whether we should kill the buttons and always search in All by default. What do others think?
Created attachment 254232 [details] [review] Patch removing the buttons Suggested patch.
If there are users of the functionality out there, suggestions on how to keep it but improving the UI (i.e. not with those buttons) are also welcome, btw.
As a data point I only search globally; however we could later try to improve how results are displayed, to avoid the current annoyance of multiple almost identical results from libraries with language bindings (this is one of the reason I know of for limiting the search to the current book).
(In reply to comment #3) > As a data point I only search globally; however we could later try to improve > how results are displayed, to avoid the current annoyance of multiple almost > identical results from libraries with language bindings (this is one of the > reason I know of for limiting the search to the current book). Yeah, improving the hitlist to add more info could be an option, although I'm not sure how to best do that. Adding an additional column, e.g. with the book title, wouldn't help much if we have a concern on the horizontal space of the hitlist itself, specially when dealing with e.g. loooong method names and such.
Hi! I'm always searching in "All books". I'm just thinking that if we want to save filtering we could use some shortcuts like duckduckgo (for instance !gi search through google images) so we could have !current to search in current book only. Buttons are killing space, and when I use DevHelp I never touch the mouse (it's too time cunsuming) I just hot Ctrl+k write some words then arrow down to the results.
(In reply to comment #5) > Hi! I'm always searching in "All books". > I'm just thinking that if we want to save filtering we could use some shortcuts > like duckduckgo (for instance !gi search through google images) so we could > have !current to search in current book only. > Buttons are killing space, and when I use DevHelp I never touch the mouse (it's > too time cunsuming) I just hot Ctrl+k write some words then arrow down to the > results. That's an option. We already have "book:" and "page:" prefixes to look for books or pages (e.g. "book:glib" takes us to the glib reference index). A new "current:" one would help.
I use the filtering option to choose a book before I search in Devhelp.My copy of DevHelp has e.g. both Gtk2 and Gtk3, so if I search "application window" two results come up and there is no indication of which is the Gtk3 result. To save time clicking on the wrong API docs I just choose a book first.
The same as Meg Ford here. I use near always only the current book filter
What about showing matches grouped by book instead of just alphabetical order?this way it becomes easy to just pick gtk3 etc
(In reply to comment #9) > What about showing matches grouped by book instead of just alphabetical > order?this way it becomes easy to just pick gtk3 etc The problem with that approach is that if the first book shows too many results, the second book won't even be shown. Think of looking for "gtk_widget_" when you have both gtk+2 and gtk+3 books installed. The number of results shown for the "gtk+3" one will be so long that the ones for "gtk+2" wouldn't be listed. Another option would be to have the hitlist ordered as is, but showing in an additional column the specific book id...
(In reply to comment #7) > I use the filtering option to choose a book before I search in Devhelp.My copy > of DevHelp has e.g. both Gtk2 and Gtk3, so if I search "application window" two > results come up and there is no indication of which is the Gtk3 result. To save > time clicking on the wrong API docs I just choose a book first. That has always been my only personal usecase for it as well, yeah. But do you really still use the gtk+2 book? I usually just disable it in preferences.
No, I don't use the Gtk2 book, but we shouldn't expect people to disable things to make our search work. Also, disabling it still means that I get multiple results from the two versions of Gtk3 Devhelp on my system, so rather than going through and finding all the cases like that I just use per-book search
(In reply to comment #10) > The problem with that approach is that if the first book shows too many > results, the second book won't even be shown. Think of looking for > "gtk_widget_" when you have both gtk+2 and gtk+3 books installed. The number of > results shown for the "gtk+3" one will be so long that the ones for "gtk+2" > wouldn't be listed. > I do not think that's an issue: gtk_widget brings up *a lot* of matches even with just gtk3, we can expect the user to just type some more to narrow the search
How about a small toggle button with a symbolic icon, in the same place as the other two? If the button is pressed, the current book is searched, otherwise all the books are searched. That would help because the overall size occupied will be smaller, and we wouldn't be scared of long translations in different languages.
Another option would be to add the toggle menuitem in the gear menu at the right side.
I implemented the logic to sort first in the hitlist those hits which are coming from the current book; or when using the special "book:" prefix. These hits will be marked with bold font weight. Code is available in the "aleksander/book-filters-update" branch in git; comments more than welcome.
Great; go and push, and this can also close 707380, 705373, 704886. You could add this bug number to commit "sidebar: remove [Current][All Books] filter buttons".
*** Bug 704886 has been marked as a duplicate of this bug. ***
*** Bug 705373 has been marked as a duplicate of this bug. ***
*** Bug 707380 has been marked as a duplicate of this bug. ***
Pushed to git master now. In a brief: * Results fro the *Current* book get sorted first, and shown in bold. * Remaining results from other books are given afterwards. * To select the current book, either: ** Select it in the book treeview ** Use the "book:bookid something" prefix; e.g. "book:gio g_type"
Sounds like a good solution. Thanks for doing this :)
*** Bug 741622 has been marked as a duplicate of this bug. ***