| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
| |
g_object_get() returns a ref to the property object. We must unref it.
(cherry picked from commit 9b62be1e1e814a0ea48a50f0ec3902927672e428)
|
|
|
|
|
|
|
|
|
|
| |
We hold a ref since commit 6b16de613dc87b9f84d87a46ac5987b6d7087a5c
But we never release it on slot destruction, so it leaks.
Release it on destruction.
(cherry picked from commit 342207ef66e3763dee08b6f208959bcfce9929b2)
|
|
|
|
|
|
|
|
|
|
|
|
| |
The saved window state (whether the window is maximized and its initial
size) should be the state, that the user would most likely want the next
opened window to start with. As the tiled state doesn't make sense
without other windows and because it's not really possible to properly
restore it, it will not be saved anymore.
Fixes https://gitlab.gnome.org/GNOME/nautilus/-/issues/1685
(cherry picked from commit 31a01278be04e19b03a29cf6636cedeb42f8a6e4)
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Tracker 3 migration code tries to spawn tracker3 binary using
G_SPAWN_SEARCH_PATH_FROM_ENVP flag. However, tracker3 is installed under
/usr/local/bin/ on OpenBSD which isn't searched by envp. So the migration fails
with the following warnings: "Tracker 2 migration: Couldn't run `tracker3`:
Failed to execute child process "tracker3" (No such file or directory)."
Let's use G_SPAWN_SEARCH_PATH instead of G_SPAWN_SEARCH_PATH_FROM_ENVP to fix
this issue.
(cherry picked from commit 4e43e9efcab6c3abfa24fbd6fe77d326358c1999)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The batch rename dialog crashes when it is opened for a second time.
This is because the TrackerSparqlConnection object is unreffed after
the first use. However, nautilus_tracker_get_miner_fs_connection
documentation clearly says that the returned should not be unreffed
because it is globally shared singleton. Let's remove the problematic
g_object_unref statement to fix the crashes.
https://gitlab.gnome.org/GNOME/nautilus/-/issues/1651
(cherry picked from commit 50edb805d2181a723a099ea09e27f325ad0864a4)
|
| |
|
|
|
|
|
|
|
|
|
| |
To correctly setup the mnemonic character following an underscore in
a checkbox label.
Closes #1630
(cherry picked from commit 74e1e6098dac3f9867382dc11b27c0fbc86508aa)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before porting to a GtkMultiPressGesture [1], for every double click,
we would get 2 events of type GDK_BUTTON_PRESS for each click and 1
event of type GDK_2BUTTON_PRESS after the second click [2]:
1st click: GDK_BUTTON_PRESS
2nd click: GDK_BUTTON_PRESS, followed by GDK_2BUTTON_PRESS
So, in order to ensure the double click happened within the same list
row, we used to save the clicked path for each GDK_BUTTON_PRESS event
and compare the last two saved paths during the GDK_2BUTTON_PRESS one.
However, now we only get a GtkMultiPressGEsture::pressed signal twice:
1st click: ::pressed is emited with n_press = 1
2st click: ::pressed is emited with n_press = 2
Yet, we are still saving the clicked path only when n_press = 1, so,
unless the user had already clicked this row before doing a double
click, the saved paths don't match and we ignore the double click.
Instead, it's enough to save the row path for the 1st click, as we
can compare it directly with row path on the 2nd click.
Fixes https://gitlab.gnome.org/GNOME/nautilus/-/issues/1599
[1] 13a8d3efacbe160d2cc9158ec707ab99013d7f87
[2] https://developer.gnome.org/gdk3/stable/gdk3-Events.html#GDK-2BUTTON-PRESS:CAPS
(cherry picked from commit 3eb0a90f6957ba099842f955255448c39f2d4a97)
|
| |
|
| |
|
| |
|
|
|
|
| |
Leftover from 4ef151871bef44e13e4d4cb65524284c68406956
|
|
|
|
|
|
|
|
|
|
|
|
| |
At the moment we restrict starring to within Home, but the database
might include URIs from outside of it. Such may happen after a file
move operation, as per the previous commit.
Keeping the moved URIs in the database is useful in case the move is
undone, because we change the URI back. But otherwise, the non-home
URIs remain in the database indefinitely.
So, let's filter them out when listing the starred files.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We don't rely on tracker-miner-fs's rename tracking for starred files
anymore, as explained in 29105fc9f6abf2eca6f986104763d21b9f22f0fb.
However, losing track of starred files, when they or their containing
folders are renamed or moved, is a major regression for this feature.
The common case is that the operation is performed using this very app,
so, we can largely restore the feature by updating URI on every rename
and move operation we perform.
Additionally, this allows us to finally close a couple of old issues.
Fixes https://gitlab.gnome.org/GNOME/nautilus/-/issues/161
and fixes https://gitlab.gnome.org/GNOME/nautilus/-/issues/169
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The sync variants of file operations have been introduced for use in
integration tests. The async operations have been suffixed _async().
However, likely by mistake, in the restore from trash operation, the
call has been appended _sync rather than _async. [1]
This blocks the main thread until the operation task finishes, causing
a dead lock when the operation thread needs the main thread to show a
conflict dialog. This happens when restoring a file from trash if a new
file with the same name already exists in the original location.
Fixes https://gitlab.gnome.org/GNOME/nautilus/-/issues/790
[1] commit ab31018cdaeb1c592e1c46402c5ae1facc503151
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Emptying trash within Nautilus is a bit slow in comparison to plain
`rm -r`. On my system, it took about 3 min to empty the trash with a
folder containing 600 000 files, which is not ideal as `rm -r` call
took just a few seconds. I found that `g_file_delete` is implemented
differently for locations provided by the trash backend. The trash
backend prevents modifications of trashed content thus the delete
operation is allowed only for the top-level files and folders. So it
is not necessary to recursive delete all files as the permission
denied error is returned anyway. Let's call `g_file_delete` only for
top-level items, which reduces the time necessary for emptying trash
from minutes to seconds...
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/1589
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code created to handle the NautilusTagManager::files-changed signal
has been reused for implemeting the NautilusDirectory::force_reload
virtual function.
This is conceptually wrong, because the update_files function doesn't
actually reload the file list. Also, as a side effect, it causes gone
files to reappear as "ghost files" (files without any attributes).
Instead, let's follow what NautilusSearchDirectory does: clear the
current file list after unmonitoring the files, and set the file list
anew the same way it's done on ::init.
Fixes:
https://gitlab.gnome.org/GNOME/nautilus/-/issues/162
https://gitlab.gnome.org/GNOME/nautilus/-/issues/167
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
This reverts commit 8efe35665368539de0e15f150292996cb0ab9121.
It aggravated a performance bug. Reverting only on stable branches.
https://gitlab.gnome.org/GNOME/nautilus/-/issues/1226
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"Extract Here", "Extract To…" and "Compress…" menu items are contained
by the extensions menu section, despite not being an extension.
This has worked fine until the extensions menu handling has been
reworked in commit bd81bd895f15c7784a2487ea7d1006910ab0cb40
This commit introduced a regressions which causes the Extract/Compress
items to disappear if actual extension menu items are added.
Since it was already conceptually wrong to have them in this section,
let's move these items into their own menu section to fix the bug.
Fixes https://gitlab.gnome.org/GNOME/nautilus/-/issues/1472
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The style check job currently fails as uncrustify from rawhide obviously
changed its behavior. It tries to change function pointer the following
way:
- gboolean (*each_function)(NautilusCanvasIcon *, gpointer),
+ gboolean ( *each_function )(NautilusCanvasIcon *, gpointer),
I don't think this is right, but don't know how to fix that ellegantly.
Note that this is because of "sp_before_ptr_star = false". Let's
hardcode the previous image varsion to avoid this change for now.
|
|
|
|
|
| |
The style check job currently fails due to the missing git command, which
disappeared after the image update. Let's add the git command explicitely.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
The fedora rawhide job fails currently as the image doesn't contain
Tracker 3 packages. Let's temporarily install the packages from
ssssam/tracker3 copr repository as they are not available yet in
rawhide repositories.
|
|
|
|
|
| |
Creation of new image currently fails on gpg signature checking.
Let's use --nogpg temporarily to make it work again.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Starred files data is now migrated from the Tracker 2.x database if
found. This depends on the `tracker3` CLI tool, which should be
present anywhere that we find libtracker-sparql 3.0. The --2to3
export functionality was added in
https://gitlab.gnome.org/GNOME/tracker/-/merge_requests/308
If/when the migration completes successfully, a stamp file named
`~/.local/share/nautilus/tracker2-migration-complete` is created.
|
|
|
|
|
|
|
|
|
| |
Previously starred files were limited to directories indexed by Tracker.
Since the 'Port to Tracker 3' commit this is no longer the case.
However, to avoid unbounded growth in the starred files database we
want to prevent starring of network locations and removable devices
for now as these entries might go stale and we don't have any way
to clean them up.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Nautilus is a file manager, so we should star files.
Previously we starred the content resources extracted by Tracker Miner
FS, instead. This had the advantage that the stars would follow file
renames. It had the downside of being more complex and limited in
which files can be starred. In Tracker 2.x, the feature only worked
in folders indexed by Tracker Miner FS. With Tracker 3.x, it was
additionally limited to files where Tracker had extracted metadata
-- mainly just documents and media files.
This commit takes the simpler approach of storing the star against
the file URL. All files can now be starred, and stars will no longer
persist when a file is moved or renamed.
Fixes https://gitlab.gnome.org/GNOME/nautilus/-/issues/160
|