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 7d80a9ad823b05b961837fa5fbf729caa5e7ca99)
We've been using GtkApplication, through a NautilusApplication method,
to set accelerators (i.e., global shortctus which trigger regardless
of where the focus is on the application window).
This will not work if NautilusWindowSlot is added to a window which
is nor a GtkApplicationWindow instance, as will be the case for the
upcoming FileChooser window.
Let's instead add them to a shortcut controller in the slow, but with
a "managed" scope which allows it to trigger even if the focus is not
on the slot.
Part of: https://gitlab.gnome.org/GNOME/nautilus/-/work_items/3411
In order for some window-level shortcuts to trigger on a FileChooser
dialog, which do not belong to NautilusApplication, we need to stop
using gtk_application_set_accels_for_action() and set the shortcuts
directly on widgets.
While at it, their GtkShortcutScope is to be changed from `GLOBAL`
to `MANAGED`. This gives us an opportunity to fully control their
scope and, thus, prevent them from being triggered while, e.g., an
AdwDialog is up.
Related to https://gitlab.gnome.org/GNOME/nautilus/-/work_items/3411
The bigger code block of activating a pending file only applies for one
caller, so the helper function did not deduplicate any code and really
only created more overhead, making the code harder to follow.
One significant side affect of this refactoring is that we don't pass
`self->pending_selection` by value to `nautilus_view_set_selection()`.
This resolves a crash in the case when `nautilus_view_set_location()`
will reach a code [1] that uses and frees `self->pending_selection`,
thus leaving the pointer passed by value for selection to become a
dangling pointer if it was pointing to `self->pending_selection`.
[1] d046bf4a8b/src/nautilus-files-view.c (L3896)
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/3036
Fix a heap overflow by designating the data type as a buffer instead
of a string in the case of a template copy and check for the operation
type to perform copying correctly.