rpms/nautilus
5
0
Fork 0
Code Issues Pull Requests Releases Activity

import nautilus-3.28.1-14.el8

Browse Source
This commit is contained in:
CentOS Sources 2020-07-28 08:33:20 -04:00 committed by Stepan Oksanichenko
parent f081904cf5
commit aff1823195
7 changed files with 269 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

35
SOURCES/file-operations-Honor-umask-when-creating-new-files.patch Normal file
View File

@ -0,0 +1,35 @@
From ee035fe0b4257d335687c038bf8b41a64d452d7f Mon Sep 17 00:00:00 2001
From: Ondrej Holy <oholy@redhat.com>
Date: Mon, 18 Nov 2019 11:34:10 +0100
Subject: [PATCH] file-operations: Honor umask when creating new files
File creation mask should be honored when creating new files from
templates as it is when creating new folders, or dragging raw data. But
it is not because G_FILE_COPY_NONE flag is specified when creating new
files from templates. Let's use G_FILE_COPY_TARGET_DEFAULT_PERMS flag
to ensure that file creation mask is honored in this case as well.
Just note that this behavior is not wanted when copying in general
(although it is also honored by "cp" cmd in this case) as it might have
some unexpected consequences as discussed on:
https://bugzilla.gnome.org/show_bug.cgi?id=167102
---
src/nautilus-file-operations.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/nautilus-file-operations.c b/src/nautilus-file-operations.c
index acf65f3cf..a90706e2e 100644
--- a/src/nautilus-file-operations.c
+++ b/src/nautilus-file-operations.c
@@ -7361,7 +7361,7 @@ retry:
{
res = g_file_copy (job->src,
dest,
- G_FILE_COPY_NONE,
+ G_FILE_COPY_TARGET_DEFAULT_PERMS,
common->cancellable,
NULL, NULL,
&error);
--
2.26.0

36
SOURCES/files-view-Clear-selection-if-any-files-don-t-match-.patch Normal file
View File

@ -0,0 +1,36 @@
From 4d7a1a7413cc7e76e99e11def90a6503cc142efb Mon Sep 17 00:00:00 2001
From: Ondrej Holy <oholy@redhat.com>
Date: Wed, 26 Feb 2020 12:56:39 +0100
Subject: [PATCH] files-view: Clear selection if any files don't match the
pattern
The Select items matching (Ctrl + S) feature allows to select files
which match the pattern. However, it is confusing that current selection
is not cleared when any files don't match the pattern.
---
src/nautilus-files-view.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/nautilus-files-view.c b/src/nautilus-files-view.c
index 5573701cc..f3d507fff 100644
--- a/src/nautilus-files-view.c
+++ b/src/nautilus-files-view.c
@@ -1716,12 +1716,12 @@ pattern_select_response_cb (GtkWidget *dialog,
selection = nautilus_directory_match_pattern (directory,
gtk_entry_get_text (GTK_ENTRY (entry)));
+ nautilus_files_view_call_set_selection (view, selection);
+ nautilus_files_view_reveal_selection (view);
+
if (selection)
{
- nautilus_files_view_call_set_selection (view, selection);
nautilus_file_list_free (selection);
-
- nautilus_files_view_reveal_selection (view);
}
/* fall through */
}
--
2.26.0

40
SOURCES/nautilus-mime-actions.c-No-Application-Installed-dia.patch Normal file
View File

@ -0,0 +1,40 @@
From 3c78251bc3bda455423807cb7fd5e25e7f8afd7e Mon Sep 17 00:00:00 2001
From: Timothy OBrien <obrien.timothy.a@gmail.com>
Date: Sun, 27 Jan 2019 12:45:28 +1100
Subject: [PATCH] nautilus-mime-actions.c: No Application Installed dialog not
closed on GTK_RESPONSE_YES
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The "There is no application installed for “foo” files. Do you want to search for an application to open this file?" dialog that appears when there is no application installed to open the specific file type is not closed after clicking Yes. Instead, it reopens again.
This patch removes code that was causing the file to be activated after the user clicked Yes; relaunching the dialog.
Resolves #842
---
src/nautilus-mime-actions.c | 8 --------
1 file changed, 8 deletions(-)
diff --git a/src/nautilus-mime-actions.c b/src/nautilus-mime-actions.c
index 6f0ad9db5..5d1d5234e 100644
--- a/src/nautilus-mime-actions.c
+++ b/src/nautilus-mime-actions.c
@@ -1191,14 +1191,6 @@ search_for_application_dbus_call_notify_cb (GDBusProxy *proxy,
g_variant_unref (variant);
- /* activate the file again */
- nautilus_mime_activate_files (parameters_install->parent_window,
- parameters_install->slot,
- parameters_install->files,
- parameters_install->activation_directory,
- parameters_install->flags,
- parameters_install->user_confirmation);
-
activate_parameters_install_free (parameters_install);
}
--
2.26.0

46
SOURCES/properties-window-Fix-endless-content-size-calculati.patch Normal file
View File

@ -0,0 +1,46 @@
From 13ecf5f9c2d219866550757cb660b569299ac285 Mon Sep 17 00:00:00 2001
From: Ondrej Holy <oholy@redhat.com>
Date: Mon, 2 Mar 2020 14:53:36 +0100
Subject: [PATCH] properties-window: Fix endless content size calculations
The total number of items and their size are shown in Properties dialog.
However, the deep count calculations are currently restarted with each
"changed" event of `NautilusFile` object(s). This is not usually a problem
if only one file is selected, but it is a pretty big issue when more
files are selected. It is common that the calculation never ends. This
is because the "changed" events are emitted in many irrelevant cases
(e.g. free space change) and it totally doesn't make sense to restart
the calculation in most of the cases. The initial idea was to react
on ongoing file operations, however, the calculation currently doesn't
react on file changes deeper in the tree anyway, or on changes, which
happened after the calculation is done. Thus the current result can be
outdated anyway.
Let's ignore `NautilusFile` changes at all when calculating the content
size as it is pretty impossible to implement this properly to dynamically
react on all size changes in the tree.
Fixes: https://gitlab.gnome.org/GNOME/nautilus/issues/363
---
src/nautilus-properties-window.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/src/nautilus-properties-window.c b/src/nautilus-properties-window.c
index 9250adbe3..52a2b3fce 100644
--- a/src/nautilus-properties-window.c
+++ b/src/nautilus-properties-window.c
@@ -1137,10 +1137,6 @@ properties_window_update (NautilusPropertiesWindow *window,
{
dirty_target = TRUE;
}
- if (changed_file != NULL)
- {
- start_deep_count_for_file (window, changed_file);
- }
}
if (dirty_original)
--
2.26.0

33
SOURCES/search-engine-tracker-Expand-macro-as-string.patch Normal file
View File

@ -0,0 +1,33 @@
From 33fafad8430ac32a750fd3315d507482c8028c15 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ant=C3=B3nio=20Fernandes?= <antoniof@gnome.org>
Date: Fri, 29 May 2020 13:16:11 +0100
Subject: [PATCH] search-engine-tracker: Expand macro as string
We have changed the FILENAME_RANK constant from being used as a format
string argument to be concatenated as a string during compilation, as
detailed in 7f00ede9b410e88106cef34c634cb46e46015e37
However, I have forgotten to quote the constant, which otherwise cannot
be treated as a string to concatenate.
Fix that now.
---
src/nautilus-search-engine-tracker.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/nautilus-search-engine-tracker.c b/src/nautilus-search-engine-tracker.c
index 571467a25..13470a62e 100644
--- a/src/nautilus-search-engine-tracker.c
+++ b/src/nautilus-search-engine-tracker.c
@@ -290,7 +290,7 @@ search_finished_idle (gpointer user_data)
* not used). The value was determined experimentally. I am convinced that
* fts:rank is currently always set to 5.0 in case of filename match.
*/
-#define FILENAME_RANK 5.0
+#define FILENAME_RANK "5.0"
static void
nautilus_search_engine_tracker_start (NautilusSearchProvider *provider)
--
2.26.2

53
SOURCES/search-engine-tracker-Fix-broken-query-under-some-lo.patch Normal file
View File

@ -0,0 +1,53 @@
From 7018cdcaa9954271cd82ba1c2620ecdfea176fae Mon Sep 17 00:00:00 2001
From: Cristiano Nunes <cfgnunes@gmail.com>
Date: Tue, 7 Apr 2020 14:47:41 +0000
Subject: [PATCH] search-engine-tracker: Fix broken query under some locales
We set a 5.0 rank for filename matches in the SPARQL query as a float
argument in a format string.
However, the floats in format strings are translated with the decimal
separator from the locale. This means in some locales the rank has a
comma instead of a dot, which results in a query error. In turn, this
effectively broke the shell search provider.
Instead of using a format specifier and passing the value as an
argument, we should just use compile-time concatenation to insert '5.0'
in the query unmodified.
Fixes https://gitlab.gnome.org/GNOME/nautilus/-/issues/1412 and #1437
Cherry-picked from 7f00ede9b410e88106cef34c634cb46e46015e37
---
src/nautilus-search-engine-tracker.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/src/nautilus-search-engine-tracker.c b/src/nautilus-search-engine-tracker.c
index 32b6039a9..571467a25 100644
--- a/src/nautilus-search-engine-tracker.c
+++ b/src/nautilus-search-engine-tracker.c
@@ -287,7 +287,7 @@ search_finished_idle (gpointer user_data)
}
/* This is used to compensate rank if fts:rank is not set (resp. fts:match is
- * not used). The value was determined experimentally. I am conviced that
+ * not used). The value was determined experimentally. I am convinced that
* fts:rank is currently always set to 5.0 in case of filename match.
*/
#define FILENAME_RANK 5.0
@@ -372,10 +372,9 @@ nautilus_search_engine_tracker_start (NautilusSearchProvider *provider)
" {"
" ?urn nfo:fileName ?filename ."
" FILTER(fn:contains(fn:lower-case(?filename), '%s')) ."
- " BIND(%f AS ?rank2) ."
+ " BIND(" FILENAME_RANK " AS ?rank2) ."
" }",
- search_text,
- FILENAME_RANK);
+ search_text);
g_string_append_printf (sparql, " . FILTER( ");
--
2.26.2

27
SPECS/nautilus.spec
View File

@ -8,7 +8,7 @@
Name: nautilus
Version: 3.28.1
Release: 12%{?dist}
Release: 14%{?dist}
Summary: File manager for GNOME
License: GPLv3+
@ -50,6 +50,22 @@ Patch26: properties-window-Fix-crashes-when-opened-multiple-t.patch
# https://bugzilla.redhat.com/show_bug.cgi?id=1646352
Patch27: search-engine-tracker-Do-not-lose-filename-results-d.patch
# https://bugzilla.redhat.com/show_bug.cgi?id=1207179
Patch28: files-view-Clear-selection-if-any-files-don-t-match-.patch
# https://bugzilla.redhat.com/show_bug.cgi?id=1566027
Patch29: properties-window-Fix-endless-content-size-calculati.patch
# https://bugzilla.redhat.com/show_bug.cgi?id=1778579
Patch30: file-operations-Honor-umask-when-creating-new-files.patch
# https://bugzilla.redhat.com/show_bug.cgi?id=1816070
Patch31: nautilus-mime-actions.c-No-Application-Installed-dia.patch
# https://bugzilla.redhat.com/show_bug.cgi?id=1847061
Patch32: search-engine-tracker-Fix-broken-query-under-some-lo.patch
Patch33: search-engine-tracker-Expand-macro-as-string.patch
BuildRequires: gtk-doc
BuildRequires: meson
BuildRequires: gcc
@ -162,6 +178,15 @@ desktop-file-validate $RPM_BUILD_ROOT%{_datadir}/applications/*.desktop
%{_datadir}/gir-1.0/*.gir
%changelog
* Fri Jun 19 2020 Ondrej Holy <oholy@redhat.com> - 3.28.1-14
- Fix broken tracker query under certain locales (rhbz#1847061)
* Fri Apr 17 2020 Ondrej Holy <oholy@redhat.com> - 3.28.1-13
- Clear selection if any files don't match the pattern (rhbz#1207179)
- Fix endless content size calculations (rhbz#1566027)
- Honor umask when creating new files (rhbz#1778579)
- Close "There is no application..." dialog after response (rhbz#1816070)
* Mon Dec 9 2019 Ondrej Holy <oholy@redhat.com> - 3.28.1-12
- Do not lose filename results due to stop words (rhbz#1646352)