Similar problem to the previous commit.
Ideally, we should simply call it "Computer", since it is the same
location. But we currently lack an effective visual clue that the
admin: backend is in use.
For that reason, label it "Administrator root" istead.
When current location is "/", the pathbar is (icon)(slash)(arrow),
which looks bad because that's 3 symbols in sequence.
Also, the slash ("/") label duplicates the pathbar separator if
current location is a child.
Instead, call it "Computer", which is the label used in Other Locations
Fixes https://gitlab.gnome.org/GNOME/nautilus/issues/414
Using GtkRecent items as search engine source in nautilus.
The main reason for this, is being able to get fast results on recently-used
files from the shell search provider.
This is disabled when recursive searches are disabled, as there's no need to go
through for recent files if no recursive (or indexed) search is enabled as the
simple engine will be already fast enough, while running this engine could be
just a waste.
This pins versions of most dependencies, uses quotes for strings and
removes header cleanup from GTK+ module, because CI pipelines choke on
them being absent when ninja decides to rebuild everything when running
tests.
(cherry picked from commit a9f13fc91f7319b318e75a95a89918e9cadf94cf)
So we allow half sized windows in 1360px screens. This is delicatily
adjusted with the default GNOME set up: Adwaita theme, only close
button as window controls and Cantarell as font.
Closes https://gitlab.gnome.org/GNOME/nautilus/issues/425
Calling _set_window_slot() in the window slot weak ref notification
callback isn’t a good idea, given that most of the stuff being cleaned
up there is done automagically, and results in runtime warnings or
potentially a segfault when removing a property binding.
This commit split nautilus_toolbar_set_window_slot(), so that property
bindings aren’t removed if called from the weak reference notification
function. Additionally, the same notification functions nulls out the
icon property binding, fixing the same thing happening in dispose().
Fixes https://gitlab.gnome.org/GNOME/nautilus/issues/441
When a file view was loaded with a pending selection, and not all the files were
seen yet, the private pending_selection list was properly free'd, but the pointer
was not cleared, causing a crash when `nautilus_files_view_set_selection` was
called again, as it was trying to deeply copy a list pointed by this invalid
reference.
So, removing the unneeded `pending_selection` temporary pointer from the main
function scope, as it only confuses, while use it (with an autolist) when we
need to pass the previous `priv->pending_selection` (stealing its ownership)
to set_selection again.
Eventually use a g_clear_pointer to free the list and nullify its priv reference
Fixes#295
In case we're searching something from the overview, we expect the same results
to be opened in nautilus, whatever the user set on the options regarding how he
wants to perform the search.
At the same way we don't want to block simple-search to run in this case if the
user has enabled recursive search, since this action is something that is
explicitly requested.
We should limit search to hidden files only when searching in overview, not when
nautilus is launched from the shell search results.
In fact, while it make sense to present only main results in the overview search,
it's better to follow user preferences when clicking on the nautilus icon on
search results, as we expect that nautilus view to go deeper if the user is fine
with searching into hidden files.
Instead of just opening a window with just the location and search terms,
we should pass to the window slot the full nautilus query with all the
shell search provider flags, so that they will be respected and that the
results in the overview will respect the ones in nautilus
Gio can provide us this info, so we can use this together with the checks
nautilus already does.
However, since there are many false-positives cases (like when using a fuse
filesystem that is actually a remote mount, like sshfs or similar), we can't
take this information as granted.
Just use settings_search_get_recursive_for_location to prompt to the user
what's going to happen, although this might not be 100% certain, if a sub-dir
is actually a network-mounted folder.
Compute the recursive parameter depending on the query flag for recursivity,
enabling it only if the query recursive flag is NAUTILUS_QUERY_RECURSIVE_ALWAYS,
while should be disabled otherwise.
At this point the "recursive" property that was set only for this search engine
doesn't make any sense anymore and we can safely drop it, together with the
calls that were done at search-engine level to handle this special case.
We move now the responsibility to to the engine itself, more than to the model.
Allow to retrieve results from search engines which are only searching on
over indexed results (tracker, recent in future), while disable them otherwise
(simple search)
Use a list of cases to define when the recursive search should be done, instead
of a simple true/false boolean.
A part from the self-explanatory cases `ALWAYS` and `NEVER`, the `IF_INDEXED`
option permits to any search engine that uses an indexed-search to return
results from subfolders of the search location.
One case we want to address, is the shell-search provider, that should not perform
recursive searches, but it could return values from subfolders of the user home
if the search is executed by search engines like tracker.
This is a reimplementation of fbe7cac0a0. There we removed the right
click menu from buttons in the pathbar except for the current location,
which actually we only allowed a left click to open the menu.
This goes with the strategy to make everything touch ready and unify the
experience, however it really prevents to perform actions in folders
that are part of the hierarchy. While I'm not sure how valuable it is,
I guess removing this would need a bit more investigation.
So to not cause much impact, this works reimplements the right click
menu with the new design and a popover.
