Design in progress
Implementation in progress
- Global Search is the center search bar at the top of the workbench
- It needs to be attached to search providers to provide individual search results
- Search providers need to optionally provide an image if we want to match the mockups
- this might be pretty difficult at first
I compared the speed of GtkTreeView and GtkListBox. GtkTreeView is still significantly faster. Creating lots of GtkWidgets is simply to costly. To avoid this with GtkListBox, we would have to make a new model backed widget. That's possible but will take some time. Additionally, GtkTreeView doesn't really give us the flexibility for the UI design we want.
So I came up with a design that allows us to show only a few results on the screen at a time. This will help keep the number of GtkWidgets created low (which was very costly in wall clock time with GtkListBox).
Since this is a primary control mechanism, speed is very much a feature.
Search Results Layout
The search result layout will tentatively look as follows. Plaintext is limiting my ability to underline, but I'd like to do some underlining of matched text as well.
+----------------+-------------------------------------------------+ | Switch To | my-widget.md [==-] | | | my-widget.ui [=- ] | | Jump to Symbol | my_widget_init [=- ] | | | my_widget_class_init [- ] | | | my_widget_do_something [- ] | | | 2 more | | Open Document | my-widget.c [==-] | | | my-widget.h [==-] | | | my-widget.ui [==-] | | | 3 more | | Read Docs For | GtkWidget [- ] | | | GtkTextView [- ] | | | GtkSourceView [- ] | | | 20 more | | Execute Action | save | | Toggle Pref | Enable VIM - use vim kegbindings in... [- ] | | Calculator | hex(3*10) = 1E | +----------------+-------------------------------------------------+
On the left, we have the action (verb) that will be performed. These will likely match up 1:1 to search providers.
To the right of that, we have the noun for which the verb will be performed. All the way to the right, is the search providers scoring of the match.
Right now, we keep the entire .git index in a fuzzy matching fulltext index. We calculate a match score while traversing the index. It's actually pretty handy for this.
I'm still not sure if we should put icons before the noun. I can see how that would help while typing the search query.
Search Result Ordering
Search results are sorted by score within their group. Groups are sorted by the priority of the search provider which created them. This is because it is very hard to create search results from searate indexes that can be compared with each other. Normally, your search score is between 0.0...1.0. Where the score falls between those two is heavily based upon the indexing algorithm you use. You can say that the score is a side-effect of that, really.
Typing a search phrase and hitting down arrow a number of times will get old. So when you know what you want to find, you'll be able to prefix your search with a letter denoting the action you care about. For example, "c MyWidget" could jump you to the definition of the "MyWidget" class.
Hide Empty Groups
If a search group does not have any results, it will not be displayed.
Search providers feed their search results into a GbSearchContext. The search context keeps enough information around to be able to render the display information. Since we've limited the amount of information we will show, we can optimize things here a bit.
If we have a maximun number of items to display in a group, it doesn't make sense to hold on to more than that. (These things take up a lot of small chunks of memory, really fragmenting things). We can always resubmit the search if they click the "X more" link. Therefore, we only need to keep a few results around after they are added to the context. (eg: those with the highest score). We should probably pass a max result count to the provider when searching so they can optimize too.