Attempting to load a collection is a programming error. Currently, that
leads to a GError and a NULL EvDocument pointer being passed to the
callback, which ends up getting handled properly. It's better to avoid
even attempting the load, in case such programming errors are dealt
with more strictly in the future.

Fallout from 70381b87

https://gitlab.gnome.org/GNOME/gnome-documents/issues/7

Local collections don't have an URI (ie. this.uriToLoad is empty).
Since commit 70381b87, whenever a single item is selected, it
is loaded to check if it can be printed. Doing this load for local
collections with an empty URI leads to an assertion inside the PDF
loader.

Attempting to load a collection is a programming error. Ideally, that
would lead to an exception being thrown, but since the base DocCommon
class passes a GError to the callback, it is better to stick to that
for consistency.

This should have been included in commit 87a04ee1, which
introduced the same check in the base class.

https://gitlab.gnome.org/GNOME/gnome-documents/issues/7

GJS' garbage collector doesn't like having the virtual function for
GtkWidget::destroy overridden. Doing that either causes a crash or
leads to CRITICALs like these:
  Gjs-CRITICAL **: Attempting to call back into JSAPI during the
    sweeping phase of GC. This is most likely caused by not destroying
    a Clutter actor or Gtk+ widget with ::destroy signals connected,
    but can also be caused by using the destroy() or dispose() vfuncs.
    Because it would crash the application, it has been blocked and
    the JS callback not invoked.

For some reason unknown to me, connecting to the signal instead of
overriding the virtual function seems to be fine. This is backed by
gnome-shell commit 98b50fd9423e57 [1] and observed behaviour.

[1] GNOME/gnome-shell@98b50fd9

https://bugzilla.gnome.org/show_bug.cgi?id=747506

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.

https://bugzilla.gnome.org/show_bug.cgi?id=791518

The getting started PDF is only useful when the user runs the
application, and is not needed by the search provider. Therefore, its
initialization needs to be removed from the common startup shared
between the application and the search provider.

However, creating the MainWindow starts the TrackerControllers. The PDF
needs to be initialized before that happens to let the
TrackerControllers include it in their queries. Synchronously
initializing the PDF makes it easier to enforce this; and since this
is happening before the UI is brought up, there's no question of
blocking it.

https://bugzilla.gnome.org/show_bug.cgi?id=791518

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.

https://bugzilla.gnome.org/show_bug.cgi?id=791518

This prevents a premature query when the TrackerController is
instantiated.

https://bugzilla.gnome.org/show_bug.cgi?id=791518

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.

https://bugzilla.gnome.org/show_bug.cgi?id=791518

Since 3.27.92, gnome-documents depends over libgepub-0.6. However,
this dependency is a runtime dependency.

This patch checks if libgepub-0.6 is avaiable.

https://bugzilla.gnome.org/show_bug.cgi?id=787013

Fallout from 759f193b

https://bugzilla.gnome.org/show_bug.cgi?id=787013