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.
Don't show Recent in the sidebar when we are in save mode.
We also ignore the startup-mode = recent in save mode now - we
don't want to populate the file list with recent files if Recent
is not on the sidebar. If you really want to go there, you can
still enter recent:// in the location entry.
https://bugzilla.gnome.org/show_bug.cgi?id=751653
In save modes, the entry is really more for entering a name than
entering a full location, so don't go there eagerly when '.', '/'
or '~' are pressed. Make Ctrl-L work better in this mode too.
Use the same code that brings up the location entry on '/',
'~' or '.' also when the focus is not on the file list. This
prevents those key presses on the sidebar from ending up in
the search entry.
Some internal containers were erroneously taking focus, interrupting
the flow of tab keynav, and using arrow keynav to go from the file
list to the sidebar did not work anymore, after the recent sidebar
rewrite.
Make the file chooser entry optionally capture Escape
and emit a signal. Make the file chooser widget hide the
entry on that signal and go back to the path bar.
This gives us a two-level undo:
location entry -> path bar -> dialog close.
When the location entry is permanently displayed in the
header for save mode, we still let the first Escape close
the dialog.
Arrange things so that hitting Escape during a running
search stops the search, but leaves the search results
around, and hitting Escape again leaves the search mode.
The location column did not work for search results in recent://.
Fix that by looking at the target uri in this case. Show the location
column in recent mode. And make it more similar to nautilus by
showing the full path if it is not below $HOME.
When the search engine provides hits with GFileInfo, use that
to add the hits to the model directly, without going through
another round of async get_info calls.
To do this, we add a batched variant of the
_gtk_file_system_model_update_file call that takes lists of
GFiles and GFileInfos. Again, we can avoid repeated resorting
that happens when the files are updated individually.
Use a revealer to manage the visibility of the header area where
we show the pathbar, the location entry or search. This is a bit
smoother, and makes search more similar to a search bar.
Since nautilus merge, we were not showing 'Recent' in the sidebar
if GIO did not support the recent: scheme. But the file chooser
can show recent files independent of gvfs - it loads the recent
files manually. This is relevant on Windows and OS X, where gvfs
is typically not used.
This commit adds a show-recent property which can be used to override
the recent: scheme check. We use it in the file chooser.
https://bugzilla.gnome.org/show_bug.cgi?id=750068
When recent files are not supported in gvfs, or turned off by
settings, we should not try to load them even if the startup
mode says so. This prevents inconsistency with the places
sidebar where 'Recent' will not appear in this case.
I managed to stall recent files today while trying to save a GTK
testcase in glade that contained enough spinning spinners that the CPU
was saturated just redrawing things.
I had to navigate the filesystem!
This signal can be emitted by GtkSearchEntry after search has been
cancelled, and other operation mode is set. It doesn't make sense to
populate the search model in that state anymore, so just avoid doing it.
https://bugzilla.gnome.org/show_bug.cgi?id=745479
