summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* ci: Use Fedora latest instead of rawhide temporarilywip/oholy/ci-buildahOndrej Holy2020-11-202-2/+2
| | | | | | | | 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.
* ci: Remove broken triage jobOndrej Holy2020-11-202-163/+0
| | | | | | | | | 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
* ci: Use Tracker 3 dependencies from Fedora repositoryOndrej Holy2020-11-201-4/+1
| | | | | The Tracker 3 dependencies are installed currently from unofficial COPR repository. Let's use the official Fedora packages instead.
* ci: Use Buildah instead of Docker to generate imagesOndrej Holy2020-11-201-11/+14
| | | | | | 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.
* tag-manager: Search for tracker3 in PATHAntoine Jacoutot2020-11-191-1/+1
| | | | | | | | | | 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.
* ci: Add libportal-devel to DockerfileFelipe Borges2020-11-181-1/+1
| | | | https://src.fedoraproject.org/rpms/libportal
* files-view: Use xdg-desktop-portal for setting WallpaperFelipe Borges2020-11-181-24/+80
| | | | | | | | 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
* build, flatpak: Add libportal dependencyFelipe Borges2020-11-186-0/+45
| | | | Fixes #795
* image properties: Handle rotated imagesJames Westman2020-11-181-4/+23
| | | | | | | | 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.
* Revert "ci: Hardcode image version for style check job"António Fernandes2020-11-181-1/+1
| | | | | | This reverts commit 831203e9512b29900e8095c91332b49bbbf97047. The previous commit fixed the issue we were working around.
* canvas-dnd: Define function type the usual wayAntónio Fernandes2020-11-181-2/+5
| | | | | | | | | | | | | 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
* batch-rename-utilities: Fix dialog crashesOndrej Holy2020-11-181-1/+0
| | | | | | | | | | | 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
* Update Turkish translationEmin Tufan Çetin2020-11-111-109/+109
|
* properties-window.ui: Set "use_underline" propertyBryan P2020-11-011-0/+1
| | | | | | | To correctly setup the mnemonic character following an underscore in a checkbox label. Closes #1630
* list-view: Fix double-click row check for gestureAntónio Fernandes2020-10-272-15/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Update Portuguese translationJuliano de Souza Camargo2020-10-231-12/+12
| | | | (cherry picked from commit c1f7f3becf78a48cab1acddf87d5fe0050eaf454)
* Update Friulian translationFabio Tomat2020-10-181-8/+8
|
* Update Portuguese translationJuliano de Souza Camargo2020-10-121-106/+106
| | | | (cherry picked from commit c31ed8fa3f330651a4006d7652325547182b9641)
* Post branch version bump to 40.alphaOndrej Holy2020-10-021-1/+1
| | | | | Let's switch to the new versioning scheme: https://discourse.gnome.org/t/new-gnome-versioning-scheme/4235
* Release version 3.38.13.38.1Ondrej Holy2020-10-023-2/+8
|
* starred-directory: Remove unused variableAntónio Fernandes2020-10-021-1/+0
| | | | Leftover from 4ef151871bef44e13e4d4cb65524284c68406956
* tag-manager: Ignore starred files ouside $HOMEAntónio Fernandes2020-10-021-1/+18
| | | | | | | | | | | | 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.
* tag-manager: Update starred URIs on move & renameAntónio Fernandes2020-10-024-2/+154
| | | | | | | | | | | | | | | | | 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
* Update Hebrew translationYosef Or Boczko2020-09-281-818/+846
|
* Update Friulian translationFabio Tomat2020-09-241-97/+97
|
* Update Russian translationStas Solovey2020-09-221-960/+1016
|
* Update Friulian translationFabio Tomat2020-09-221-120/+120
|
* file-utilities: Don't block main thread to restore from trashAntónio Fernandes2020-09-211-3/+4
| | | | | | | | | | | | | | | | | 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
* file-operation: Prevent recursion to speed up emptying trashOndrej Holy2020-09-211-2/+14
| | | | | | | | | | | | | | | | 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
* Update Central Kurdish translationJwtiyar Nariman2020-09-211-1467/+1155
|
* starred-directory: Deduplicate file unmonitoringwip/antoniof/they-re-here-to-save-the-worldAntónio Fernandes2020-09-191-41/+17
|
* starred-directory: Actually implement ::force_reloadAntónio Fernandes2020-09-191-6/+25
| | | | | | | | | | | | | | | | | | 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
* Add Kabyle translationSelyan Slimane AMIRI2020-09-182-0/+5608
|
* Update Chinese (Taiwan) translationCheng-Chia Tseng2020-09-181-456/+462
|
* Update Portuguese translationJuliano de Souza Camargo2020-09-161-597/+182
|
* Revert "file: use emblems for files that use default icon"António Fernandes2020-09-141-22/+1
| | | | | | | | This reverts commit 8efe35665368539de0e15f150292996cb0ab9121. It aggravated a performance bug. Reverting only on stable branches. https://gitlab.gnome.org/GNOME/nautilus/-/issues/1226
* Update Latvian translationRūdolfs Mazurs2020-09-121-941/+997
|
* Release version 3.38.03.38.0Ondrej Holy2020-09-113-2/+6
|
* Update Italian translationMilo Casagrande2020-09-101-833/+817
|
* files-view: Add Extract/Compress menu sectionAntónio Fernandes2020-09-081-1/+3
| | | | | | | | | | | | | | | | "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
* ci: Hardcode image version for style check jobOndrej Holy2020-09-071-1/+1
| | | | | | | | | | | | | 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.
* ci: Add missing git dependencyOndrej Holy2020-09-071-1/+1
| | | | | 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.
* Update Slovak translationDušan Kazik2020-09-061-5/+5
|
* Updated Danish translationAsk Hjorth Larsen2020-09-061-959/+991
|
* Update Hungarian translationBalázs Meskó2020-09-051-940/+999
|
* ci: Add Tracker 3 dependenciesOndrej Holy2020-09-041-0/+4
| | | | | | | 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.
* ci: Disable gpg signature checkingOndrej Holy2020-09-041-2/+2
| | | | | Creation of new image currently fails on gpg signature checking. Let's use --nogpg temporarily to make it work again.
* Release version 3.37.923.37.92Ondrej Holy2020-09-043-2/+6
|
* Import starred files data from Tracker 2.xSam Thursfield2020-09-024-1/+178
| | | | | | | | | | | 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.
* Limit starred files to within user's home directorySam Thursfield2020-09-026-142/+24
| | | | | | | | | 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.
View Lorry Controller Status