1. 07 Apr, 2021 2 commits
  2. 06 Apr, 2021 1 commit
  3. 26 Mar, 2021 1 commit
  4. 25 Mar, 2021 1 commit
  5. 23 Mar, 2021 2 commits
  6. 08 Mar, 2021 4 commits
  7. 05 Mar, 2021 1 commit
  8. 07 Dec, 2020 5 commits
  9. 20 Nov, 2020 1 commit
  10. 19 Nov, 2020 1 commit
    • Antoine Jacoutot's avatar
      tag-manager: Search for tracker3 in PATH · 5f07c8db
      Antoine Jacoutot authored
      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 4e43e9ef)
  11. 18 Nov, 2020 1 commit
    • Ondrej Holy's avatar
      batch-rename-utilities: Fix dialog crashes · d94c25be
      Ondrej Holy authored
      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.
      (cherry picked from commit 50edb805)
  12. 11 Nov, 2020 1 commit
  13. 02 Nov, 2020 1 commit
  14. 27 Oct, 2020 1 commit
    • António Fernandes's avatar
      list-view: Fix double-click row check for gesture · 6faab068
      António Fernandes authored
      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] 13a8d3ef
      [2] https://developer.gnome.org/gdk3/stable/gdk3-Events.html#GDK-2BUTTON-PRESS:CAPS
      (cherry picked from commit 3eb0a90f)
  15. 23 Oct, 2020 1 commit
  16. 12 Oct, 2020 1 commit
  17. 05 Oct, 2020 4 commits
  18. 02 Oct, 2020 4 commits
  19. 28 Sep, 2020 1 commit
  20. 24 Sep, 2020 1 commit
  21. 22 Sep, 2020 2 commits
  22. 21 Sep, 2020 3 commits
    • António Fernandes's avatar
      file-utilities: Don't block main thread to restore from trash · 553e59f6
      António Fernandes authored
      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 ab31018c
    • Ondrej Holy's avatar
      file-operation: Prevent recursion to speed up emptying trash · 36e505c1
      Ondrej Holy authored
      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
    • Jwtiyar Nariman's avatar
      Update Central Kurdish translation · 9f344bfc
      Jwtiyar Nariman authored