The view.properties action opens the current directory properties when
the selection is NULL, which we assume to be the case when opening the
background context menu.
Instead of relying on this assumption, make the background context menu
use the view.current-directory-properties action which is used by the
current location menu in the pathbar. Also, rename view.properties to
view.selection-properties and specialize it.
In the past, nautilus_pop_up_context_menu_at_pointer() was the common
path for popping up context menus from the view and pathbar.
However, different paths were introduced in
commit 29cf64bd76 and
commit 489d4d091e, which
share some code but couldn't use this API.
Now that the pathbar context menus are gone, this is actually
causing more code duplication while making it harder to read.
Instead, handle everything in files-view.c.
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.
