trackerController: Assert against premature queries
The TrackerControllers are only supposed to issue their queries once
all the pieces of the application that are necessary to formulate them
have been initialized. This is indicated by the invocation of the start
method. For example, if the queries are submitted before the detection
of the getting started PDF has completed, then they won't have the
path to PDF and it will be missing from the UI.
Throwing an exception forces one to think about the details surrounding
each query submission path, as opposed to having the silently dropping
the request.
application: Tie the catch block more tightly to the failure site
Having a lot of code inside a try statement makes it harder to follow
the error handling logic. The catch statements are far away from the
code that can throw an exception, so it is difficult to match them
together. Let's reduce the size of the try blocks by only using them
for fallible operations.
application: Make window creation complete asynchronously
Creating MainWindow starts the TrackerControllers. The getting started
PDF needs to be located before that happens, to let the
TrackerControllers include it in their queries. Since, locating the PDF
is an asynchronous operation, the overall _createWindow method also
needs to complete asynchronously.
This doesn't make any user-visible changes, but sets the stage for the
subsequent patches.
application: Insert the getting started PDF only when showing a window
The startup is shared between the application and the search provider.
There is no need to initialize the getting started PDF for the search
provider, since it is only useful when the user runs the application.
