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
The search engine might stay alive longer due to extra temporary refs, so
the signal handlers should be removed for the filechooser to ignore these
properly.
https://bugzilla.gnome.org/show_bug.cgi?id=745479
Avoid scrolling animation when scrolling to where we want
to insert the new folder, since adding the entry doesn't
do the right thing if the treeview is still scrolling.
An alternative would be to wait for the animated scrolling
to reach its target before starting the editing, but this
is easier.
https://bugzilla.gnome.org/show_bug.cgi?id=729366
We were trying to start search when the user types anything,
but this is annoying more often than helpful, and interferes
with the location entry. So, stick with explicitly enabled
search (via the search button or Alt-S) for now.
Add a button to allow restricting search to the current
folder (and subdirectories). This makes the search more
useful, and makes the file chooser more similar to
nautilus.
In search, we show files from differnt locations, and it makes
sense to show where they come from. This makes the file chooser
more similar to nautilus, too.
Folders that show up among search results were unexpectedly
returned even for GTK_FILE_CHOOSER_ACTION_OPEN. Change things
around so that we switch to the folder instead, which is the
behavior we had in GTK+ 2.x.
https://bugzilla.gnome.org/show_bug.cgi?id=744204
It is a bit misleading to have one of the places in the sidebar
selected while in search mode, since the search is not relative
to any location. So, unset the sidebar selection when we enter
search mode.
If the search entry doesn't consume the key event, don't
change to search mode. Otherwise, we interfere e.g. with
Ctrl and Shift keys for selection.
https://bugzilla.gnome.org/show_bug.cgi?id=743660
