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.
In the network view, if the row is not selected, clicking the unmount
button does nothing. Indeed, the action is still disabled, despite an
elligible item being selected already.
This happens because the actions state is updated on idle along with
the context menus. This is reasonable as the context menus update can
be expensive.
However, not updating actions state imimediately is unexpected, so
let's immediately update them when selection changes.
Unmount and eject are already doing this since commit 80dd8fb8ff
Let's do the same for mount and stop, and use g_autoptr() to emphasize
the callback taking ownership of the reference passed to the method.
Otherwise, nautilus_file_can_unmount() will still return FALSE for
a file which is already mounted, until the can-unmount attribute
is updated asynchronously by the file monitor.
This is needed for the next commit to be able to check whether
unmount is possible as soon as the mount operation completes.
We have barely been exposing to these file types since the Computer and
Network places were replaced by Other Locations.
Now that NautilusNetworkDirectory brings them back into use, we need
to account for their special status.
Both mountables and shortcuts to folders open in view, acknowledge it.
And use mountable target URI (if available) as its activation URI.
