[Builder] Global Search

[Christian Hergert <christian hergert me>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Everyone!

Builder today has something that pretends to be global search.  It's not
really that powerful, and was mostly just about seeing what UI ideas
will work.  In particular, I wanted to see what it would be like to
implement things with GtkListBox instead of GtkTreeView.

Global Search will be very central to Builder, so it's time to focus
more on the design.

## Performance Restrictions

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.

## Shortcuts

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 Context

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.

## Implementation

It's unlikely that I'm going to have this done for 3.15.4, but I am
going to get started on it imminently.  If anything does land, it will
be limited to refreshing the Git search provider as a test.


- -- Christian

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIbBAEBAgAGBQJUti74AAoJEDTRnfr1IpSGQAQP938pMydtNBl5K7pI5WK3yQhZ
8Js+/ZPWglqaxmb/0C1FgQPlzo28eUu6Pdspmz4ozQGqwATAXAis46m3zf7hMBXg
IyA+TToyAu7wavtRLdQ86PWfFnQJI+5aixV/Xay00pxJ0J8JlES2/1foy9hQvjCa
iOScFBjEbbk3KvK7EDOoUlHmCemv4n78945+6yhl49gx6edVwRe88QHDPjEsd0MW
FR/aw7gcozd6ReH1jEN0YoEG1sd5QK3zBrCP9MstwPPgMdEVvkoPdoH71fJcDVBz
Vkt2hV/l4a9O6jdC2G3hqdYfHFGCRkHEYcmdhHNv6EXaiineZSqoZY1GRzyN0MmC
R5139eEoy779z53jW0svV+uCPpQeJtIlzNDrVcy25ge1MZH2LjWBFzFQ9N267Pht
7ocwOAP6erERPrDVVkhl60OmGh/ZIrPF7KssPwRAD2qi5o3aKlhtficFzGv/rfUC
T0MoiYw/P15br7g4G27nNUkquF/tYBTxuEa9f3nmawYlkgw1ZgqekfccVoPToc/r
libusOoRSOw4iiCqc3mK6wwungwcPFI1phj2vZuPWHRDZujbDylhUtAvRHrYA/MT
pE6GdBfa6wLHv2lPD3f9RkSHZNi7hBJDZbveQnhzIVt4kQf2h1/lK/yjiZrJdvkj
N/2ldpOkqDJHhc3aMzQ=
=bb9E
-----END PGP SIGNATURE-----