This has to be the shortest-living object in GTK history!
It helped us greatly during the transition to GtkColumnView, but
now we can remove it in favour of GFileInfo directly. Perhaps I
could have never introduced GtkFileSystemItem in the first place,
but we're 30 commits deep and it's too late to just redo the whole
thing that will get us exactly here anyway.
We now start a mini-series of commits that will ultimately remove
the GtkTreeModel implementation of GtkFileSystemModel.
As a first step, port GtkSearchEngineModel iter through the files
using GListModel API.
It is necessary to signal the search engine that we are finished and
that we found something for it to reliably show the results. It would
sometimes work anyway since it is sufficient if any backend signals
completion. However if GtkSearchEngineModel was the only backend
returning results then things would break.
The main GDK thread lock is not portable and deprecated.
The only reason why gdk_threads_add_idle() and
gdk_threads_add_idle_full() exist is to allow invoking a callback with
the GDK lock held, in case 3rd party libraries still use the deprecated
gdk_threads_enter()/gdk_threads_leave() API.
Since we're removing the GDK lock, and we're releasing a new major API,
such code cannot exist any more; this means we can use the GLib API for
installing idle callbacks.
https://bugzilla.gnome.org/show_bug.cgi?id=793124
Make GtkSearchHit carry a GFile instead of an uri. Most of the
search engines already have the object around, and converting
to an uri and back is unnecessary extra work.
This search engine reuses the GFileInfo that is already loaded
for the file list, to ensure that hits from the current directory
always appear promptly.
