Currently, it caches the view selection through bindings.
Unfortunately, this cache may get out of sync with the view, because
NautilusView:selection is a file list that's generated on-demand, and
NautilusView::notify:selection is unreliable. E.g. when the view
switches to a new location, it empties the model, which effectively
clears selection, but this is not notified as a selection change.
Making NautilusView:selection's notifications reliable is going to
require quite a bit of refactoring, so that's for another time.
Drop the binding and proxy the selection property without caching it.
Instead of reimplementing GtkFileFilter, which conveniently takes
the GVariant format from the FileChooser portal interface, let's
wrap it with a filter of our own which translates NautilusViewItem
into a dummy GFileInfo.
To make them reusable in the upcoming FileChooser window.
Reuse the slot.open-location and add macro for actions with arguments.
The "win.go-home" action is preserved for the pad controller, which
doesn't support passing parameters to actions.
Part of https://gitlab.gnome.org/GNOME/nautilus/-/work_items/3413
This is going to allow the upcoming FileChooser portal implementation
to attach its window as a modal dialog to client applications, even
if they use different display servers (X11 and Wayland).
Make it a private static library to be used in commming commits.
Contrary to upstream, we use the imported *.impl.* definitions.
For convenience (not to move a lot of meson code around), define
the HAVE_GTK_WAYLAND and HAVE_GTK_X11 in config.h instead of
compiler flags.
These are copied from [xdp-desktop-portal], to avoid adding it and all
its dependencies as buildtime dependencies of our own (and to the
flatpak manifest).
[xdp-desktop-portal]: https://github.com/flatpak/xdg-desktop-portal/
`x11_interop` is the symbol of a global variable, but gets reused for
a local one.
We should try to keep this code in sync with xdp-desktop-porta-gnome
so, instead of chaning the symbol, ignore the compiler error.
This is code copied from xdg-desktop-portal-gnome repository today[0].
We need it to implement the FileChooser portal ourselves.
It's not included in the build yet, as it needs modifications first.
[0] b92a8cc5f6
When asked to open the URI leading to an archive file, the slot
marks the file for extraction as soon as the view is loaded.
In FileChooser modes we wouldn't extract anyway, since activation
is handled by the slot. But it would lead to other unexpected
results, like immediately sending the file to the portal as result.
This is really a corner case but let's avoid it anyway.
The view handles activation through mime-actions.c functions, which
allow, among other things, opening files in other apps.
We don't want that in the FileChooser modes. Opening folders is okay,
but what we want to do when double-clicking a file depends on the
exact mode and the filters that apply.
Prepare to handle activation at a higher lever: the expected action
will be implemented by the upcoming NautilusFileChooser, by handling
the new NautilusWindowSlot::activate-files signal.
While the FileChooser will not want to launch files in handler apps
on activation, it still needs to activate items that open in view.
For regular folders it would be trivial, but for mountables it would
have to reimplement logic that's already present in mime-actions.c
In order to make it possible to use `nautilus_mime_activate_files()`
from the FileChooser to open items in view, we need to stop relying
a NautilusApplication method, because the upcoming FileChooser will
not be a NautilusApplication window.
Since we already pass the slot as a pointer, we can just use the slot
method directly, which produces the same effect here anyway.
Disable 35 actions, to ensure they cannot be activated (e.g. by
keyboard) even if not found on context menus:
"paste"
"paste_accel"
"create-link"
"create-link-shortcut"
"new-folder-with-selection"
"open-with-default-application"
"open-with-other-application"
"open-current-directory-with-other-application"
"open-item-new-window"
"open-item-new-tab"
"cut"
"copy"
"create-link-in-place"
"create-link-in-place-shortcut"
"move-to"
"copy-to"
"delete-from-trash"
"star"
"unstar"
"delete-permanently-shortcut"
"delete-permanently-menu-item"
"permanent-delete-permanently-menu-item"
"remove-from-recent"
"restore-from-trash"
"paste-into"
"extract-here"
"extract-to"
"compress"
"send-email"
"console"
"current-directory-console"
"properties"
"current-directory-properties"
"run-in-terminal"
"set-as-wallpaper"
Additionally disable "new-folder" in OPEN mode, as it is still wanted
in SAVE mode.
Note: "open-scripts-folder" in theory should also be disabled, but it's
not worth the effort, as there is no shortcut, no menu item, and no harm
(it would just open a Files application window).
Part of: https://gitlab.gnome.org/GNOME/nautilus/-/work_items/3414
The slot is already a construct property, so it makes sense to
complete the initialization on `constructed()` instead.
This paves the way to do rely more on the slot during construction.
The slot and its internals are going to be reused by the upcoming
FileChooser window, as part of a FileChooser portal implementation.
However, some behaviors and UI elements are going to be different.
So, the slot needs to know on which mode to operate from the start.
There are 3 FileChooser portal methods[0]:
- OpenFile
- SaveFile
- SaveFiles
But OpenFile has 2 boolean options ("directory" and "multiple) which
mean there are actually 4 modes:
1. select single file
2. select single folder
3. select multiple files
4. select multiple folders
As such, we have 6 new modes to support, in addition to the "browse"
mode (i.e., business as usual).
[0]
https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.FileChooser.html
The "start-icon" property is already set with the property bind between
the bookmark and the row in the same function, and the GIcon reference
generated by calling `nautilus_bookmark_get_symbolic_icon()` is not
dropped.
nautilus-bookmark-list is sending changed signals in the same callstack
where the rename button is pressed, which is before the popover is
unmapped. And thus is causing the sidebar to rebuild the rows, destroying
the row before the unmap callback is called on the row.
Change the binding of the signal to the lifetime of the row instead of
binding it to the sidebar.
This fixes a crash when renaming bookmarks.
This was a small oversight in [1] that causes crashes when trying to
drag and drop new bookmarks after opening a new window and closing
the old one.
[1] 26480b7017
Instead of sending a signal for NautilusWindow to open the requested
location, send it directly. This will make it easy to reuse the sidebar
in the upcoming FileChooser dialog.
Part of https://gitlab.gnome.org/GNOME/nautilus/-/work_items/3431
The commit[0] which introduced this comment aimed to fix a bug which was
caused by double-clicking a folder on the view.[1]
This change was ineffective as per later comments on that bug report,
which is not surprising because the change was wrong: this code path was
(and still is) used only for changing locations using the pathbar and
sidebar. The bug happening with double-click on the view is uses another
code path, in mime-actions.c, which has later been patched[2].
So, let's remove the wrong FIXME comment and effectively revert [0],
which, as expected, doesn't introduce any bug in my testing.
[0] 49c03251ee
[1] https://bugzilla.gnome.org/show_bug.cgi?id=756499
[2] 755c771058
Instead of having NautilusWindow relay the change, have the sidebar
talking directly with the window slot.
This prepares the sidebar to be reused in the upcoming FileChooser
dialog which is not going to be a NautilusWindow.
Part of https://gitlab.gnome.org/GNOME/nautilus/-/work_items/3431
The public GtkPlacesSidebar in GTK3 couldn't make assumptions about a
place that was private to nautilus, so it would emit a specific signal
instead of regular ::open-location.
Now that it's all nautilus-internal, there is no reason not to use the
regular ::open-location signal. This way NautilusWindow doesn't have
to handle the special signal, which makes the upcoming FileChooser
implementation simpler.
Part of https://gitlab.gnome.org/GNOME/nautilus/-/work_items/3431
Around the 3.0 release, the sidebar featured section headers and there
was a section whose header was "Computer".
We still carry that name in an enum symbol. It makes no sense nowadays
if you don't know the history. So, let's rename it to the name by
which it is informally called in current design mockups.
The sidebar has got too many unremovable places at the top, which leave
little space for other potentially more relevant places before they
overflow out of view by scrolling.
A set of special user directories (DOCUMENTS, MUSIC, PICTURES, VIDEOS,
and DOWNLOAD) are found near the top, and cannot be removed, even if
people don't need quick access to all of them.
Bookmarks (i.e. custom locations added to the sidebar by the users) are
always at the bottom, which means they are the first to go out of view.
This is made worse by internal storage units being back to the sidebar.
To fix these issues, let's reorganize the places:
- reduce the number of default sidebar locations by turning the
special user directories into regular bookmarks[0] that people can
reorder or remove from the sidebar.
- show bookmarks before mounts; this allows special user locations to
remain close to their previous position, keep important bookmarks from
being scrolled out of view, and instead overflow excess mounts/devices.
While at it, reposition the Home to the first place, as it is the first
location shown when launching the app.
Part of: https://gitlab.gnome.org/GNOME/nautilus/-/issues/3012
[0] This assumes a default set of bookmarks including these directories
is created by xdg-user-dirs-update-gtk on first login. Ensuring it
is installed, running on startup, and working correctly is a system
integration and quality assurance task for vendors/administrators.
We use some application-internal URIs without a corresponging GVFS
backend. If we let NautilusVfsFile handle the file info requests when
loading these locations, we get a G_IO_ERROR_NOT_SUPPORTED error, as
should be expected.
Nowadays, none of our internal URI schemes go through NautilusVfsFile:
* `x-nautilus-search://*/` URIs lead to the creation of instances of
the `NautilusSearchDirectoryFile` subclass;
* `x-network-view:///` and `starred:/// lead to the creation of
instances of the `NautilusInternalPlaceFile` subclass.
This means that `call_when_ready()` requests for these files do not ask
for a GVFS to handle unsupported URI schemes. So, we no longer get a
G_IO_NOT_SUPPORTED error when getting info on these locations.
As such, let's no longer ignore such errors.
These used to be hidden in Other Locations view. Now that they live in
the sidebar, let's sort them last, in order to avoid pushing external
volumes (e.g. plugged-in devices or connected remotes) down the list
and possibly out of view.
Let's keep external volumes above the recently returned internal ones.
Part of: https://gitlab.gnome.org/GNOME/nautilus/-/issues/3012
Previously, the only way to "save" a remove server connection was
bookmarking it. So, we have an action in the sidebar just for that.
Now that we have a new Network view making previous connections easy
to find, there is no need to promote this action from the sidebar.
Furthermore, adding mounts to bookmarks is problematic because:
- for local mounts it makes no sense and results in errors when
trying to use a bookmark to an unmounted partition[0]
- for remote mounts, it results in a duplicated sidebar entry[1].
Drop this action from the sidebar menu, not to encourage using it.
[0] https://gitlab.gnome.org/GNOME/nautilus/-/issues/858
[1] https://gitlab.gnome.org/GNOME/nautilus/-/issues/607
