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
The slot accesses the window's tab view to change the selected tab.
This is a layer violation, which is both completely unnecessary and
is getting in the way of reusing the slot widget in a tabs-less
window (such as the upcoming FileChooser window).
So, have NautilusWindow manage the selected tab directly. This is
one less NautilusWindow method being called by NautilusWindowSlot.
Part of https://gitlab.gnome.org/GNOME/nautilus/-/work_items/3402
We'v been relying on a gtk_widget_grab_focus() call to avoid broken
focus states after view (re)loading.
But there is one particular case where we must not do it: if the
popover menu is shown. This is a rare situation which is currently
only possible to trigger by pressing [Spacebar] while the "Show
Hidden Files" menu item has focus.
But this currently relies on the slot calling a NautilusWindow method,
which is a layer violation which is getting in the way of reusing
NautilusWindowSlot in the FileChooser window[4].
Let's use generic GTK/GDK API to assess wether the menu is shown,
and drop the NautilusWindow method.
Originally I've just removed the grab_focus() call, but came to
realize it was still needed, so let's also document my findings here.
Part of: https://gitlab.gnome.org/GNOME/nautilus/-/work_items/3402
The selection check is done after the emission of delayed singals which
may change it, as per commit 09f4546d50.
However, nowadays we have a habit of combining declaration and
assingment into a single statement. So, during future hacking, one
might be tempted to move the assignments into the declaration lines,
effectively reverting that commit.
Let's keep declaration and assingment together but after that call,
and also add a comment to make it clear this order is intentional.
We've not been dropping handles properly, and we've been getting
warnings from gdk_wayland_toplevel_real_unexport_handle() as such.
This is because we are passing the "wayland:"-prefixed string, but
the actual wayland export handle is only the part after the colon.
Fixes a regression from commit ad865de618
(cherry picked from commit 4fc8812040)
Add starring and unstarring actions to the pathbar context menu.
In order to disallow starring the home directory, add a new function to
the tag manager, which checks if a given directory can be starred.
If the file is destroyed before the mount operation is completed,
we cancel the mount operation.
However, due to the nature of GAsyncResult, the callback is still
called in a future iteration of the main loop, when the file is
long gone. But since it's passed as callback data, we try to
cast it, with predictably bad results.
Access the file pointer only if the operation hasn't been cancelled.
