Disables pasting in the context menu and shortcuts with specific error
dialogs. Previously, pasting into these directories using 'ctrl-v'
triggered strange error dialogs. The Trash folder also had paste enabled
in the menu.
Fixes#3235
Usage page was embedded into privacy and we didn't update the
code to reflect that. Change the name in the dbus request to
launch the containing panel, and also specify the subpage name.
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/3348
When copying files from readonly mounts we only reset the permissions of
the source if those are of filesystem type isofs. The original behaviour
was meant to be a workaround for isofs optical disks [1][2] for which the
kernel driver sets permissions of all inodes to r-x if the POSIX
permission extension (rock ridge) is not available [1].
As we can't detect the presence of such an extension from gio we can only
guess and reset the permissions for all isofs mounts. This is still
wrong [3], but reduces the scope of the bug to isofs.
[1] https://bugzilla.gnome.org/show_bug.cgi?id=167102
[2] https://bugzilla.gnome.org/show_bug.cgi?id=550816
[3] https://gitlab.gnome.org/GNOME/nautilus/-/issues/2873
This was supposed to be done in ee6ee07543
The select action called by this focus function would set the
selection and notify the changes which updates the selection info
in the floating bar.
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/3354
When debugging, knowing the file uri might be helpful. Generally it is
not helpful though, as it might faciliate users exposing private file
names in bug reports.
- stylise the whole indicator to be like a sidebar item
- adjust the spacing and padding and pixel-size in the UI file
(Ammended by António Fernandes <antoniof@gnome.org>)
The changes in commit c653f880 ("list-base: Don't inherit
from NautilusFilesView"), broke our gestures on the empty status page
which is still a child of files-view. Rather than attempt to fix this
through files view, as done in commit 95f3db44 ("files-view: Add
gestures to open background menu in empty view"), which fixed the click
gestures, but not the dnd gestures, let's make the more appropriate
change of making the empty status page a child of list-base.
Having the empty status page as a child of the list-base is more logical
because it represents the view, and ultimately our goal is to remove
all view components for files-view (despiste its name).
The empty page is still managed externally, to make it reusable accross
view mode changes. Being an overlay also allows its visibility to be
externally controlled.
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/3309
(Commit message originally by Corey Berla)
This reverts commit 95f3db44c8.
As suspected, this isn't enough. The DnD gestures also need to work
on the empty view. Revert this fix and in the next commit we'll move
the empty view to be a child (within a stack) of the list-base.
When navigating to an invalid location (i.e. through the location
entry, a bad bookmark, etc), the file add/changed handlers are no
longer present in the view until another location change (or reload)
happens. The existing call to nautilus_window_slot_set_viewed_file()
is not enough to fully reestablish the handlers which were removed from
the call to nautilus_window_slot_stop_loading() (which
ultimately calls disconnect_directory_handlers() in files-view).
There's an explicit comment introduced at [1] which makes it clear
that we want to remove these handlers early for performance and search
reasons. Otherwise we could have delayed removing the handlers which
would have allowed us to not call nautilus_window_slow_force_reload() at
all. But since this invalid location is just a corner case which
most likely won't happen, let's keep the typical case optimized.
Alternatively, we could create a new function in files-view to
only reconnect the handlers but that too seems to open up a can of
worms for little return.
This bug was introduced in [1]
[1] 9e1e14db2f
