| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
The previous commit implements invoking the main context for the dialog
from an operation thread. This duplicates existing code that caters the
same use case for the file conflict dialog (using the
`invoke_main_context_sync()` function). Let's move the code handling of
the password dialog into the `src/nautilus-operations-ui-manager.c` file
to make use of `invoke_main_context_sync()`.
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/1829
|
|
|
|
|
|
|
|
|
|
| |
Currently, an empty string is passed to gnome-autoar if the archive
extraction password dialog is cancelled. This is not problem currently
as immediately the `abort_job` function is called, however, it would
be nice to return `NULL` to make obvious that the prompt dialog was
cancelled.
https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/657#note_1084750
|
|
|
|
|
|
|
|
|
|
|
| |
When extracting encrypted archives, Nautilus randomly crashes when opening
the password dialog. This happens pretty often under X11, but I have
already seen a few crashes on Wayland as well. I suppose that all those
crashes are caused because the password dialog is constructed on the
extraction thread and GTK is not thread-safe. Let's modify the code to call
GTK on the main thread only to fix those crashes.
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/1825
|
|
|
|
| |
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/1811
|
|
|
|
|
|
|
|
|
| |
The `validate-desktop`, `validate-desktop-autorun-software` and
`validate-appdata` meson tests fail currently because of the updated meson.
This is because of the recent change, which requires explicit specification
of dependencies. Let's specify them to fix the pipeline.
https://gitlab.gnome.org/GNOME/gnome-build-meta/-/issues/372
|
| |
|
|
|
|
|
| |
This is the style we use, but we were missing the uncrustify
configuration for it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The network access is no more needed for gvfs support as it currently
uses named sockets instead of abstract ones. It is enough to allow access
to `xdg-run/gvfsd` folder, where the named sockets reside. I'm not aware
of other reasons for allowing network access. Let's drop the network
access. This also workarounds "Too many open files" errors caused by
leftover sockets (GNOME/gvfs#542).
Relates: https://gitlab.gnome.org/GNOME/gvfs/-/issues/515
|
| |
|
|
|
|
|
|
|
|
|
| |
This addition follows the logic of adding back RAR
support in gnome-autoar[1]
Closes #1813
[1] - https://gitlab.gnome.org/GNOME/gnome-autoar/-/commit/9356fae1a735b9f8e9daf5633b9709596543ff2e
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
I made 40 release yesterday by mistake. Let's use 40.0 instead to
ensure the correct sort order.
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/1807
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
| |
Reuse existing strings with approximate meaning.
|
| |
|
| |
|
|
|
|
|
|
|
| |
Commit [1] has reinstated a regression from the earlier commit [2].
[1] 080f83385ff79a8be54ee31e7a45422138226f1f
[2] 02ba130f3d61fae414459cb308adf270edb01e6e
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Now that the async files opening path is only used while sandboxed,
the conditions for these if blocks (not being sanboxed) is never met.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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] f5206a6daf0991d91e885a28bb66795a8ae12a41
[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 475684ac9e556b144da594bf25581560d4fa5a7f.
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 1f77023b5769c773dd9261e5294c0738bf6a3115
and its fixup commit be53569b339b4494647758a9afa0fdd30184455b
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] c4afd14696c670db8fbb64dcc4ea2f0807d25a94
[2] d95a616116bb8c02b01261afa3ed5b581f9f2e74
[3] https://blogs.gnome.org/antoniof/2021/03/05/files-40-beta-more-productivity-and-some-eye-candy/#comment-541
|
| |
|
| |
|
| |
|
| |
|
| |
|