We already have an action to show location entry via a keybinding,
however a new user may be confused because nowhere hints the keybinding.
ADd a menu item to the menu in pathbar so user can easily find it and
then paste or edit the location.
Nautilus does not scroll correctly for forward or backward navigation.
This is because the behaviour of the action "list.scroll-to-item" does
not put the specified position at the top of the view, but rather
scrolls the minimum amount to bring it to view, which usually leaves it
at the bottom of the view.
So, instead save the last visible item to scroll to.
Fixes https://gitlab.gnome.org/GNOME/nautilus/-/issues/2720
(Ammended by António Fernandes <antoniof@gnome.org>)
Banners are currently one of the "extra_location_widgets", which get
destroyed and recreated whenever the location changes. This setup
precludes the usage of the reveal functionality of AdwBanner, which
is desired by the design team.
Setup the banner separately from the extra location widgets (of which
x-content-bar is the only left possible element now). Make it a direct
child of the slot which can be reloaded as many times as needed.
GtkInfoBar is deprecated in GTK 4.10. Use AdwBanner introduced in
libadwaita 1.3 instead.
This makes having a custom struct to store all the information
redundant, so drop the NautilusSpecialLocationBar class and provide
a method to create an AdwBanner instead.
Part of #2722.
Make it consistent with other infobars with a button and add mnemonic.
Fixes https://gitlab.gnome.org/GNOME/nautilus/-/issues/2402
(Factored out by António Fernandes <antoniof@gnome.org> from Peter's
original commit)
We are going to change from GtkInfoBar to AdwBanner.
So, the GtkInfoBar::response signal is going away. In preparation,
isolate the reusable parts of its callback in functions that can
be used as calbacks to the AdwBanner::button-clicked signal.
(Factored out by António Fernandes <antoniof@gnome.org> from Peter's
original commit.)
When switching view mode, a new view is created. If we are in a search,
the new view has no previous location to go back to when canelling
search, so it falls back to the user home directory.
In order to improve this situation, let's have the new view assume that
the queried location is the original location.
(This fails for global search, but the proper fix requires larger
changes, which are not suited for a bugfix in the stable branch.)
As follow-up to not treating search as a navigation node[0], I've
removed some intrincate logic to handle the case where we go back or
forward to a search directory.[1]
Except... this logic was also needed for the case where we reload a
search directory in a new view during view mode (grid/list) change.
As a consequence, switching view mode during search results in an
empty results view, even if there were some before.
So, let's restore the important bits that were removed in [0].
Fixes https://gitlab.gnome.org/GNOME/nautilus/-/issues/3114
[0] commit d06b4d6a81
[1] commit 570e5c59c3
The properties dialog of a file or directory accessed using the admin
backend allows changing its owner. The list of possible users for this
gets populated from passwd. If one of the users in passwd has an empty
GECOS field, this will cause get_real_name() to use g_strsplit() on an
empty string, which means geco_parts[0] is NULL, leading to a crash when
passed to g_utf8_validate().
Fix this by not doing anything when we encounter an empty GECOS field.
Closes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/3111
%lu probably works in most cases, but on 32-bit musl (not sure
about glibc) it complains about that %lu expects
"long unsigned int" but time_t is "long long int". As such, work
around this by copying what gnome-desktop does for this case.
Pressing the Menu key while the view is scrolled down causes the view
to jump up, which shouldn't happen.
This happens because of a faulty reimplementation of an edge case
handling in the GTK4 port. It's utterly broken and it's my fault.[0,1]
- The index from the selection filter model is wrongly applied
to scroll the view (as if it was the index of the unfiltered
model);
- If the `for` loop runs until the end, the `i` is not the
index of the last item: it's the length of the filter model.
- For list view, the focus child is the inner list view, not
the cell's parent, so this logic would work only in grid.
The first two points are fixable using GtkBitset instead of
GtkSelectionFilterModel, but the last point means this would
still not work under list view.
The proper solution requires a way to query the focus position,
which doesn't exist (yet? [2]).
Let's give up on the smart handling of corner cases and just get
the common case right. Even in the corner cases, this simple
solution is not too bad.
Fixes https://gitlab.gnome.org/GNOME/nautilus/-/issues/3095
[0] 809049a3f6
[1] b28e2d545d
[2] https://gitlab.gnome.org/GNOME/gtk/-/issues/2891
We save sort options when the state of the view.sort action changes.
But this state may be changed in cases where the user hasn't changed
the sort options. Such is the case when the folder is loaded and we
read preferences and metadata to update the state of the sort action.
As a result, visiting a folder for the first time causes the default
sort setting to be saved as metadata and remembered in future visits.
This makes the setting moot except for never before visited folders.
This also causes us to save metadata unnecessarily.
Instead, sort metadata should be saved only when the user explicitly
changes the sort order form the default on each folder. To enforce
this, block our handler of state changes when updating from settings
and metadata.
Resolves a partial regression https://gitlab.gnome.org/GNOME/nautilus/-/issues/2931#note_1784938
The previous commit had already moved the metadata reading part.
NautilusListView and NautilusGridView still set the action state,
and NautilusFilesView listens to the state change.
Resolve 2 TODOs. Also remove outdated comment (update_context_menu()
doesn't activate the view.sort action at all.
Preferences signal connections are moved upclass too, because
their handler is update_sort_order_from_metadata_and_preferences().
This helps with preparing to move more things upclass, as per the
plan from https://gitlab.gnome.org/GNOME/nautilus/-/issues/3042
