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
The last remaining direct interaction between NautilusWindow and the
location entry are the location prompt actions.
Let's do everything in the toolbar instead, to make it easy to reuse
in the upcoming FileChooser dialog. Now the location entry is entirely
private to the toolbar.
Part of: https://gitlab.gnome.org/GNOME/nautilus/-/work_items/3431
There is no need for the window itself to do it. This will ensure
they are handled the same way in the upcoming FileChooser window.
Also fix signal parameter type to reflect the assumed object type.
Part of: https://gitlab.gnome.org/GNOME/nautilus/-/work_items/3431
When the location entry is shown, we remember the previous focus widget
to restore the focus back into it when the location entry is hidden.
This only happens before or after asking the toolbar to show/hide it,
so, we can instead have the toolbar handle this behavior itself.
Replace the setter with explicit open and close methods which handle
the focus. These can also be conveniently used as callbacks.
This way, when the toolbar gets reused in the upcoming FileChooser
window, this behavior will also exist there.
Part of: https://gitlab.gnome.org/GNOME/nautilus/-/work_items/3431
Instead of the window, it makes more sense to have the toolbar update
its own children. The role of the window should be only to connect
the active slot with the toolbar, then let them talk among themselves.
This makes it easier to reuse the toolbar in the upcoming FileChooser.
(While touching nautilus_toolbar_set_window_slot_real(), also remove
unused variable.)
Part of: https://gitlab.gnome.org/GNOME/nautilus/-/work_items/3431
Test sandbox program has been moved from the `TinySPARQL` (previously
`tracker`) project to `localsearch` (previously `tracker-miners`).
067e855151abc100fa6b
We've avoided the trivial case of cancellation on destruction, as part of
commit 16b81477b3
But there may be cases where the async task returns an error even before it's cancelled,
but the async callback is only called in a future iteration where the file is already
destroyed. So, handle that case too and add a warning while at it.
(cherry picked from commit 7d80a9ad82)
