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)
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.
We need NautilusWindowSlot to be reusable in the FileChooser window.
This means it cannot assume its parent is a NautilusWindow.
For NautilusWindowSlot code, rely on gtk_widget_get_root().
For NautilusApplication we can assume a NautilusWindow ancestor.
Part of: https://gitlab.gnome.org/GNOME/nautilus/-/work_items/3402
We have a whole branch of dead code under the condition that a window
is not visible. This is dead code because, as of GTK4, the :visible
property is TRUE by default; but even before that, I doubt the window
wasn't presented already before this callback.
The logic on this conditional branch is ancient[0] and employs rather
drastic measures: destroy the window if it failed to load its initial
location. At a later point[1], a special case hase been added not to
destroy the window if there is no other nautilus window. It would open
Home instead, or, failing that, the filesystem root. But if both fail,
it would still resort to destroying the window.
Not only is destroying the window unecessary, the special case of a
single application window assumes NautilusWindowSlot can only exist
inside a NautilusWindow (belonging to NautilusApplication). This is
going to be a problem for the FileChooser window, which will not be
a NautilusWindow, not belong to the NautilusApplication, but still
run in the same process.
Let's drop the dead branch. But salvage the handling of rare cases
where $HOME fails to load for some reason.
Part of https://gitlab.gnome.org/GNOME/nautilus/-/work_items/3402
[0] commit 4ce7b8ead3
[1] commit 06f5c77133
We've been expecting NautilusFilesView to pass a window handle to
nautilus_previewer_call_show_file(), requiring it to call async
methods from NautilusWindow to get them.
There are a few problems with this approach:
1. It's a layer violation for the view to call into the window.
Not only is this conceptually wrong, it's keeping us from
reusing the view in other windows which are not NautilusWindow
instances, like as the upcoming FileChooser window.
2. It's leaking details of the NautilusPreviewer2 D-Bus API into
NautilusFilesView and NautilusWindow, namely the expected format
of the window handle.
3. Even though this format is a de-facto standard nowadays, we are
not using it for anything else, so there is no value in keeping
it in NautilusWindow API.
4. Even if we start using it for other purposes, there it nothing
specific to NautilusWindow in how to generate a window handle;
it's the same process for any toplevel surface.
5. Tying the window handle's validity to the lifetime of the
NautilusWindow instance means we keep it exported even if no
longer used by the previewer, and in theory we would use the
same handle for multiple peers.
So, have NautilusFilesView pass a generic GtkRoot pointer instead
and handle the exporting and unexporting lifetime of window handles
in the previewer glue code instead.
The NautilusWindow API, no unused, is also removed. If the need arises
in the future to reuse this export/unexport logic, we can always move
it into ui-utilities.c or something like that.
Part of: https://gitlab.gnome.org/GNOME/nautilus/-/work_items/3402
Middle click on back/forward buttons opens the previous/next location
in a new tab.
We want to reuse the history controls for FileChooser window, but it
will neither have tabs nor be a NautilusWindow at all.
So, make this feature conditional on the root widget being an instance
of NautilusWindow.
Part of: https://gitlab.gnome.org/GNOME/nautilus/-/work_items/3402
We want to make the pathbar reusable for the FileChooser window,
which is neither going to be a NautilusWindow nor part of the
NautilusApplication instance.
But we don't really need anything from the application or window
classes which cannot be done directly with the slot class. And
the slot is going to be reused in FileChooser too.
In order to have access to the slot, expect the pathbar owner
(currently only NautilusToolbar) to set it as a property. The
FileChooser is going to be able to set the slot itself as well.
Part of: https://gitlab.gnome.org/GNOME/nautilus/-/work_items/3402
We have "container" boxes in the .ui file to which we add the
actual widgets in code.
I believe this was done back when we desired these UI files to
be editable in Glade, which didn't know our custom widgets.
But we no longer care about that, so let's do everything in the
UI template. This will make the next commit simpler by enabling
bindings to be declared in the UI template as well.
We can ask the slot directly whether it is the active one.
This removes one NautilusWindow method call from inner widgets,
which is a layer violation and gets in the way of reusing them
for the upcoming FileChooser window.
Part of: https://gitlab.gnome.org/GNOME/nautilus/-/work_items/3402
These actions have been living in the window, but they are actually
implemented by the slot, and conceptually they are slot actions.
Import them in preparation to use them also in the FileChooser window.
Part of https://gitlab.gnome.org/GNOME/nautilus/-/work_items/3413
We do so in two cases: active slot change, or :allow-stop change.
Have the window handle both cases: it is the one who changes active
slot already, and listening to NautilusWindowSlot:allow-stop changes
is trivial.
This resolves a layer violation and is one fewer NautilusWindow
method being called by NautilusWindowSlot, preparing the later for
reuse in the FileChooser portal dialog window.
Part of https://gitlab.gnome.org/GNOME/nautilus/-/work_items/3402
This is used by NautilusFilesView, which is a layer violation. But
it's also useless, because the only thing it does is sync the
start/reload actions, and that's already done by the slot calling
nautilus_window_sync_allow_stop() anyway in the same situations
(i.e. when view starts or ends loading).
Drop it, to prepare the view to be reusable in FileChooser dialogs.
Part of: https://gitlab.gnome.org/GNOME/nautilus/-/work_items/3402
Like the previous commit, this resolves a layer violation and paves the
way for NautilusWindowSlot to be reusable in future FileChooser dialog,
by not using NautilusWindow methods.
On this particular case, we have been updating window widgets which
depend of current location whenever the active lot changes or the the
location of the active slot changes.
On the first case, the window is in charge of setting the active slot,
and in the second case it is already listening to the locatio change.
In both cases, on_location_changed() in nautilus-window.c is called.
So, sync the location widgets from on_location_changed() and stop
exposing it in the header.
Part of https://gitlab.gnome.org/GNOME/nautilus/-/work_items/3402
We rely on the slots calling sync_title() on the window, which is
wasteful (if the slot is not active), fragile, and a layer violation.
We already have properties for all of these pieces, so let's use
expressions. This also helps with preparation for FileChooser window,
as we need NautilusWindowSlot to stop calling NautilusWindow method,
as part of https://gitlab.gnome.org/GNOME/nautilus/-/work_items/3402
We call it to assert the slot being set as inactive is (still) active.
Not only is this counter intuitive, but it also relies on order of
events in nautilus_window_set_active_slot(). Therefore, the assertion
is useless because we already rely on NautilusWindow doing it right.
Instead, make the caller of nautilus_window_slot_set_active() (i.e. the
window) responsible for ensuring consistency. To ensure it is not set
by any other means, make the property read-only.
One less NautilusWindow method being called by NautilusWindowSlot, as
part of https://gitlab.gnome.org/GNOME/nautilus/-/work_items/3402
