| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While dragging items over the list view, the row which accepts drops in
the current pointer position has its top border highlighted, but not the
bottom border, as indended by the default stylesheet.
This had already been fixed.[1] The regression happened because GTK has
stopped using .dnd style class, instead using :drop(active).[2]
The previous fix ([1]) consisted in not highlighting any border at all,
with the rationale that "we already modify the icon to hint about dnd".
This is based on the assumptions that:
1. folder icons change to the folder-open icon;
2. folders are the only drop targets.
But these assumptions do not hold:
1. the folder-open icon is not used if a folder has a custom image
instead of the default icon, or if a thumbnailer is installed;
2. some non-folder items, such as archive files, accept drops too.
So let's fix this the other way around: highlighting both borders,
above and below, as intended by the default stylesheet.
Closes https://gitlab.gnome.org/GNOME/nautilus/-/issues/1525
[1] https://gitlab.gnome.org/GNOME/nautilus/-/commit/4963cd7d564b633299f8e31bb8ac10f67eae6477
[2] https://gitlab.gnome.org/GNOME/gtk/-/commit/12c5ca5c013e035374ad1590b0e64cb7a452aa30
|
|
|
|
| |
They cut on boilerplate and improve readability.
|
|
|
|
|
|
|
|
|
| |
- Use GList API instead of reimplementing it:
- g_list_copy_deep()
- g_list_foreach()
- g_list_delete_link()
- NULL-initialize fully-owned lists.
- Don't reimplement nautilus_mime_get_default_application_for_file()
|
|
|
|
|
|
|
|
|
|
|
|
| |
When showing the properties for multiple files with the same MIME type,
The app_info variable is reassigned multiple times in a for loop to
the return value of nautilus_mime_get_default_application_for_file(),
which returns a caller-owned refference.
So, we leak a reference on each reassignment.
To fix this, declare the variable inside the loop block, to ensure
autocleanup after each loop iteration.
|
|
|
|
|
|
|
| |
Also fixes a few leaks:
*uri in setup_volume_usage_widget()
*error in set_as_default_clicked_cb()
*message in set_as_default_clicked_cb()
|
|
|
|
| |
Use modern GLib utilities for memory management.
|
|
|
|
|
|
|
|
|
|
| |
It's wrong to set a pointer to an object as data without incrementing
its refcount.
But there is actually no need to pass a real pointer as data here, as
we actually want a boolean.
Use a pointer conversion macros instead.
|
|
|
|
|
| |
Use "self" as symbol name for the NautilusPropertiesWindow* instance
in methods and signal handlers.
|
|
|
|
|
|
| |
ROW_PAD was a macro used by code the UI creation
code which has been removed in previous commits.
Now It's not useful.
|
|
|
|
| |
Unused since commit bd30a21a0ce1b40ca59814f731bd761670601aaa
|
|
|
|
|
|
|
| |
This reverts commit e3031953e40b4fe067d566ac6c403127d7b6c266
It worked around an issue in tracker, which is fixed now:
https://gitlab.gnome.org/GNOME/tracker/-/issues/252
|
|
|
|
|
|
| |
get_query_status() is a wrapper for tracker_sparql_cursor_next_finish()
and it's weird for _finish() not to be called directly by the
GAsyncReadyCallback function.
|
|
|
|
| |
See https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/553#note_989920
|
|
|
|
| |
Fixes: https://gitlab.gnome.org/GNOME/nautilus/issues/1319
|
|
|
|
|
|
|
|
|
|
|
| |
The default location (i.e. g_mount_get_default_location) should be
used when opening mounted, but we should not use it instead of the root
button in the path bar. Because it is currently impossible to navigate
to parent folders if default location is set. Let's change
nautilus_get_mounted_mount_for_root logic and return mount only for
root path so we can see the real root in the path bar.
https://gitlab.gnome.org/GNOME/nautilus/issues/1319
|
|
|
|
| |
(cherry picked from commit 8e67058fb368146183f0159292fa5ab483d9c4e9)
|
|
|
|
|
| |
Replace a guard check if/else statement with an early return and
minimize unnecessary function calls.
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
Since commit ece6b825, xdg-desktop-portal is used to set wallpapers. This
introduced the following build warning: "‘set_wallpaper_fallback’ defined
but not used", because the fallback is used only if it is built without
libportal support and it is not guraded by #ifdef. Let's use the fallback
also in the case of xdp_portal_set_wallpaper portal failure, which fixes
the warning as well.
|
|
|
|
|
|
|
| |
GNOME CI runners have been updated to the latest libseccomp so the
problem should no longer happen.
This reverts commit ab55380f200e5ea03116c5871607d125deff844c.
|
|
|
|
| |
(cherry picked from commit b62f9a7422edd181c92ef0d0ccce7b8d91860497)
|
|
|
|
|
|
|
|
| |
The pipeline currently fails with Fedora rawhide, because g-ir-scanner fails
with failures like: "ldd: error: you do not have read permission for
`/builds/GNOME/nautilus/_build/tmp-introspectgwhh729q/Nautilus-3.0'".
This obviously affects more projects:, e.g. GNOME/grilo!62. Let's use
Fedora latest for now as a workaround.
|
|
|
|
|
|
|
|
|
| |
The triage job is broken, which regularly causes CI failures. I've
made some attemts to fix it but I failed. I don't have capacity to
spent more time on it. Let's remove the job completely for now to
prevent the confusing CI failures.
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/1625
|
|
|
|
|
| |
The Tracker 3 dependencies are installed currently from unofficial COPR
repository. Let's use the official Fedora packages instead.
|
|
|
|
|
|
| |
The GNOME runners are no more privileged and thus it is not possible to
use Docker from the pipeline. Let's use Buildah instead Docker to fix
the image generation.
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
https://src.fedoraproject.org/rpms/libportal
|
|
|
|
|
|
|
|
| |
If libportal was found during build, we can use libportal to set
the Wallpaper. Otherwise, we fallback to the old Nautilus behavior
of directly copying the image and updating the gsetting.
Fixes #795
|
|
|
|
| |
Fixes #795
|
|
|
|
|
|
|
|
| |
Images with EXIF metadata can contain an orientation tag, which indicates the
image should be rotated. In the Image tab of the Properties dialog, swap the
width and height if the image is rotated by 90 or 270 degrees.
Fixes #1590.
|
|
|
|
|
|
| |
This reverts commit 831203e9512b29900e8095c91332b49bbbf97047.
The previous commit fixed the issue we were working around.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Defining an function type inline as a function parameter is a awkward
syntax and not used in our codebase except for this one occurence.
Although valid C, it confuses our style check tools, breaking the CI
style check [1] and failing to align parameters.
Instead, let's define a named function type to use as parameter type,
and fix parameter misalignment.
[1] 831203e9512b29900e8095c91332b49bbbf97047
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
To correctly setup the mnemonic character following an underscore in
a checkbox label.
Closes #1630
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 c1f7f3becf78a48cab1acddf87d5fe0050eaf454)
|
| |
|
|
|
|
| |
(cherry picked from commit c31ed8fa3f330651a4006d7652325547182b9641)
|
|
|
|
|
| |
Let's switch to the new versioning scheme:
https://discourse.gnome.org/t/new-gnome-versioning-scheme/4235
|
| |
|
|
|
|
| |
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
|