summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
* search-engine-simple: Handle case when mime type is NULLOndrej Holy2023-03-091-1/+1
| | | | | | | | The `G_FILE_ATTRIBUTE_STANDARD_CONTENT_TYPE` attribute doesn't have to be always set. This case is not handled by the `NautilusSearchEngineSimple` class and the `NULL` pointer can be passed in the `g_content_type_is_a` function currently. This is an error. Let's check the returned pointer to prevent this situation.
* Use generic helpers for obtaining file attributesOndrej Holy2023-03-094-15/+39
| | | | | | | | | | | | | | | | | | | | It is not guaranteed that all `GFileInfo` attributes are always set when requested. They used to be silently set to `NULL`, `FALSE`, or `0` earlier when they were not provided by their implementations. However, some of the helper functions now print critical errors when the attributes are not set by their implementations even though they were requested. See the https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3261 merge request for more details. So Nautilus now prints tons of critical errors when started. The unset attributes can be detected over the `g_file_info_has_attribute` function. But Nautilus doesn't care in most cases about the reason why the attribute is `NULL`, `FALSE`, or `0`. There are also more generic helper functions that don't print these critical errors. Let's use them for the attributes that may not always be set to get rid of those critical errors. I suppose that the `name`, `display_name`, `size`, `icon`, and `file_type` attributes don't need this special handling, although it is not clearly stated anywhere... Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/2861
* Update Persian translationMohammadSaleh Kamyab2023-03-061-865/+929
|
* Post release version bumpOndrej Holy2023-03-051-1/+1
|
* Release version 44.rc44.rcOndrej Holy2023-03-053-2/+14
|
* file: Cache clock format settingCorey Berla2023-03-051-9/+20
| | | | | | | | We are already caching the preferences for thumbnailing. Since the clock format is queried for every single file when loading a list view, we should also cache the clock format setting. Rename the flag from use_24 to use_24_hour for more clarity.
* file: Don't emit files_changed in file_class_initCorey Berla2023-03-051-4/+16
| | | | | | | | | | | | | In nautilus_file_class_init, we are calling thumbnail_limit_changed_callback() and show_thumbnails_changed_callback() in order to cache the initial values for the static variables cached_thumbnail_limit and show_file_thumbs. This has the unintended side effect of also calling emit_change_signals_for_all_files_in_all_directories () which doesn't make sense at a point in time when there are no NautilusFile's and NautilusDirectory may not even be ready. Split out the updating of the setting from the emission of all files changed.
* directory: Prevent usage of uninitialized hash tableOndrej Holy2023-03-051-0/+5
| | | | | | | | | I see regularly the following debug print on Nautilus startup: `GLib-CRITICAL **: 10:52:52.992: g_hash_table_foreach: assertion 'hash_table != NULL' failed`. This is because the `emit_change_signals_for_all_files_in_all_directories` function is called before the `directories` hash table is initialzed. Let's return early to prevent usage of the uninitialized hash table.
* freedesktop-dbus: Try to own the name until after exporting skeletonOndrej Holy2023-03-041-16/+15
| | | | | | | | | | Currently, the `g_bus_own_name_on_connection` function is called for the `org.freedesktop.FileManager1` name before exporting the `/org/freedesktop/FileManager1` skeleton. This seemingly works fine in most cases, but occasionally the name is acquired too early and D-Bus clients can get `No such interface` error. This is regression caused by the commit 2293e813d3cd1cc47b2b8750f7140647aa066fc8. Let's try to own the nam until after exporting the skeleton to avoid this error.
* Revert "window-slot: Unref new location"Corey Berla2023-03-041-2/+0
| | | | | | This reverts commit d45b820d4a082287ef52f538fc001009ad5204e1. This commit causes a crash.
* Revert "window-slot: Make ownership transfer of pending location explicit"Corey Berla2023-03-041-1/+4
| | | | | | | This reverts commit 16c0a9b102e99ec7aa3c880e034d8aa7b9c5b4f7. This commit builds on commit d45b820d4a082287ef52f538fc001009ad5204e1 which causes a crash.
* file-operations: Exchange error messages used when deletingOndrej Holy2023-03-041-6/+6
| | | | | | | | There are two error messages that may be shown when the delete operation fails. One message is generic and the another one mentions insuffient permissions. However, the generic one is now shown in the case of the `G_IO_ERROR_PERMISSION_DENIED` error. Let's exchange the messages to use the second one in this case.
* Update Korean translationChangwoo Ryu2023-03-041-740/+830
|
* Update Chinese (Taiwan) translationChao-Hsiung Liao2023-03-041-721/+794
|
* Update French translationAlexandre Franke2023-03-031-736/+818
|
* Update Hungarian translationBalázs Úr2023-03-031-718/+814
|
* flatpak: Remove --talk-name=org.gtk.vfsOndrej Holy2023-03-021-1/+0
| | | | | | | | The `--talk-name=org.gtk.vfs` statement should not be used in manifests as there is no service with such name. The `--talk-name=org.gtk.vfs.*` statement should be pretty enough for the GVfs access. See: https://docs.flatpak.org/en/latest/sandbox-permissions.html#gvfs-access Let's drop that statement.
* Update Finnish translationJiri Grönroos2023-03-011-869/+941
|
* list-base: Don't free calls to nautilus_view_model_get_item_from_fileCorey Berla2023-03-011-1/+1
| | | | | | | | Now that we are properly freeing all view items, it became obvious that we were incorrectly freeing a call to get_item_from_file which is just a hash table lookup. See: https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/1101
* list-base: Sort after file-changesCorey Berla2023-03-011-0/+4
| | | | | | | | | | | | | | | | | | | When renaming a file in list-view or grid-view, the renamed file keeps its position (i.e. it isn't re-positioned into the new proper position) until a refresh). There is actually a more generalized problem where file changes on all attributes fail to cause the sort positions to be updated. For example, sorting by date modified and touching a file doesn't cause a re-sort. The file-changes signal from nautilus-directory, simply gives us the changed files for a given directory, without telling us what was changed so there's not an efficient way of detecting this. We do have a ::end-file-changes signal, that is only emitted once every batch of changes, so let's call nautilus_view_model_sort() then. If no sort changes are required, this will finish quite fast, so it seems like the best alternative. Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/2568
* Update Slovenian translationMatej Urbančič2023-02-281-893/+978
|
* Updated Spanish translationDaniel2023-02-281-16/+19
|
* Update Danish translationAlan Mortensen2023-02-261-853/+932
|
* Update Bulgarian translationAlexander Shopov2023-02-261-726/+818
|
* Update Occitan translationQuentin PAGÈS2023-02-231-3/+3
|
* Update Turkish translationSabri Ünal2023-02-221-5/+5
|
* general: Change libadwaita include pathBarnabás Pőcze2023-02-1919-19/+19
| | | | | | | | | | | | | | | | | | | | | | | The libadwaita pkg-config adds `-I/usr/include/libadwaita-1` (or similar) to the compiler flags, which means that #include <adwaita.h> is sufficient, and the currently used #include <libadwaita-1/adwaita.h> is not necessary. Not only is it not necessary, but it prevents nautilus from being built with an uninstalled libadwaita build (either meson subproject or otherwise). To fix that, remove the `libadwaita-1/` prefix. The libadwaita test programs also only `#include <adwaita.h>`, and according to Debian Code Search, that is the more popular version. https://codesearch.debian.net/search?q=%23include+%3Cadwaita.h%3E&literal=1 https://codesearch.debian.net/search?q=%23include+%3Clibadwaita-1%2Fadwaita.h%3E&literal=1
* nautils-search-engine-tracker: Only parse non-null datesPablo Correa Gomez2023-02-191-7/+16
| | | | | | | | | | | Fix critical when parsing null date string: GLib-CRITICAL **: 12:05:52.144: g_time_val_from_iso8601: assertion 'iso_date != NULL' failed This is possible since tracker can return NULL[1] "if the column is not in the [0,#ncolumns] range" [1] https://gnome.pages.gitlab.gnome.org/tracker/docs/developer/tracker-sparql-cursor.html?gi-language=c#tracker_sparql_cursor_get_string
* Update German translationJürgen Benvenuti2023-02-181-1097/+854
|
* Update Friulian translationFabio Tomat2023-02-171-999/+1080
|
* Update Turkish translationSabri Ünal2023-02-141-5/+5
|
* Post release version bumpOndrej Holy2023-02-111-1/+1
|
* Release version 44.beta44.betaOndrej Holy2023-02-113-2/+17
|
* Update Occitan translationQuentin PAGÈS2023-02-081-855/+935
|
* Add Faroese translationBogi Napoleon Wennerström2023-02-082-0/+5822
| | | | (cherry picked from commit c1ebea52a5f653dcd55a20c10b8f74423c0d19dd)
* appdata: State hardware supportChristopher Davis2023-02-081-0/+8
| | | | | | | Declare what sort of hardware we support and the minimum display size Nautilus is usable on. This allows applications like Software to display hardware information or hide the app on incompatible hardware.
* desktop: List compatible form factorsChristopher Davis2023-02-081-0/+1
| | | | | | List the form factors the app was designed for in the desktop file. This is so desktop environments like Phosh and Plasma Mobile can show or hide the app in the correct contexts.
* flatpak: Use -Dbattery_detection=none for tracker-minersOndrej Holy2023-02-071-1/+2
| | | | | | | | | | The flatpak jobs are broken currently, because the tracker-miners project fails to build due to missing upower-glib depenedency. It is used to tweak the behavior when running on battery. It used to be automatically disabled until the following MR: https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/1121. I suppose it is safe to disable this functionality as our flatpak isn't meant for production. Let's explicitely disable that to fix our pipeline.
* file-operations: Fix inverted g_assert conditionOndrej Holy2023-02-061-1/+1
| | | | | | | | | | | The commit e2969a9c29d0d171038fcb35d8baa5a7df372191 introduced an assertion statement to ensure that the `g_file_get_basename` returned non-NULL string. Unfortunately, the assertion has an inverted condition. This leads to crashes in the `get_unique_target_file` function for files that don't have the `edit-name` attribute set (i.e just a few GVfs backends). Let's fix the inverted condition. Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/2825
* Update Turkish translationSabri Ünal2023-02-061-9/+11
|
* Update German translationJürgen Benvenuti2023-02-051-631/+673
|
* Update Catalan translationJordi Mas2023-02-041-834/+927
|
* Update Galician translationFran Dieguez2023-02-011-1431/+901
|
* Update Spanish translationDaniel Mustieles2023-02-011-874/+952
|
* Update Indonesian translationKukuh Syafaat2023-02-011-845/+927
|
* Update Russian translationAleksandr Melman2023-01-291-622/+687
|
* Update Basque translationAsier Sarasua Garmendia2023-01-281-839/+923
|
* Update Lithuanian translationAurimas Černius2023-01-281-743/+817
|
* Update Ukrainian translationYuri Chornoivan2023-01-271-626/+726
|
* Update Hebrew translationYosef Or Boczko2023-01-271-3/+4
|
View Lorry Controller Status