While sandboxed, we add the first file in the queue to recents.
This has two problems:
* The file is added to recents even if we fail to launch.
* If opening multiple files, we forget to add the others to recents
Instead, add each file to recents for each successful launch.
While sandboxed, we open files using the OpenURI portal, and we don't
know which app is the default handler app for each file. As such, we
have given up group-launching files with the same default handler when
adapting nautilus to being sandboxed.[0]
But this resulted in a feature regression in the non-sandboxed case,
which is still the common case in production.
Reinstate the code for the old behaviour[1], but keep the current
behaviour when running in inside a flatpak sandbox.
Closes https://gitlab.gnome.org/GNOME/nautilus/-/issues/117
[0] f5206a6daf
[1] based on revert patch with revert conflicts resolved by hadess
This pointer may be NULL. Usually this may happen only during window
initialization and destruction. However, for robustness, make sure
every use either handles a NULL pointer or asserts it's non-NULL.
We used to explicitly set the active slot when closing a tab. However,
we now let GtkNotebook pick the next tab, and wait for ::switch-tab to
set the active_slot field to the one GtkNotebook picked, thanks to
commit 475684ac9e.
However, if the closed tab was the only tab in this window, then
::switch-tab is never called, so active_slot becomes a dangling
pointer, crashing the application when trying to close the window.
Use a weak reference to ensure the pointer is set to NULL in that case.
Fixes https://gitlab.gnome.org/GNOME/nautilus/-/issues/1759
After removing the non-default "icons on desktop" functionality from
nautilus, a gnome-shell extension was created as a substitute. This
extension needed to interoperate with nautilus for file operations,
but its access to clipboard was limited to plain text, so, in order to
ensure interoperation, nautilus had to use plain text clipboard only.
However, this temporary regression resulted in implementation details
leaking into the text clipboard, instead of a plain file path.
But now St.Clipboard can handle any type of clipboard content[1], the
extension will be able to handle any clipboard type, so we can finally
fix this regression on our side.
This reverts commit 1f77023b57
and its fixup commit be53569b33
Fixes https://gitlab.gnome.org/GNOME/nautilus/-/issues/634
[1] GNOME/gnome-shell@ec367623
It was set to flathub because we used to depend on a stable runtime. [1]
We have since changed to depend on the unstable runtime[2], but the
Nightly flatpakref still configures the wrong repo on
installation. If the user didn't have the gnome-nightly repository
configured in advance, then the runtime cannot be found, failing the
installation.[3]
Update the repo URL, which I should have done in [2].
[1] c4afd14696
[2] d95a616116
[3] https://blogs.gnome.org/antoniof/2021/03/05/files-40-beta-more-productivity-and-some-eye-candy/#comment-541
