| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
There's a race condition for when Nautilus checks for Sushi's
"Visible" property and decides whether a selection change should
update the previewed file.
By avoiding calling Sushi when the selected file is the same as
the last one previewed, we can workaround the race condition.
Fixes #1823
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When running an executable text file as a program, it's reasonable to
expect that the directory currently displayed by the file browser
becomes the current working directory for that program. This used to be
handled correctly by the activation action.
While taking "Run as a Program" out of activation into a standalone
action, this behavior was left behind.
Let's add it back to the standalone action to fix the regression.
Fixes https://gitlab.gnome.org/GNOME/nautilus/-/issues/1842
|
| |
|
| |
|
|
|
|
|
| |
Mostly to remember callers must be ready to handle a NULL return value,
trying to prevent more bugs like the one fixed by the previous commit.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new filename entry has the automatically suggested part of the name
selected for convenience since 9108b4028b7f476b598bc664079fd6d115801b66
However, the logic for this relies on extensions offsets, causing
crashes when failing to handle the extensionless case, which is common
for folders.
So, improve the logic here to handle extensionless filenames, looking
at their length instead.
Fixes https://gitlab.gnome.org/GNOME/nautilus/-/issues/1841
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
| |
|
| |
|