Currently, hidden files are filtered out when looking for template files.
However, it would be nice to have a way to create hidden files from templates.
Let's offer hidden files as templates, but only when hidden files are shown.
Fixes: https://gitlab.gnome.org/GNOME/nautilus/issues/1320
We are near 3.36, so let's update the dependencies.
gexiv2 git master is failing to build locally, so I've
updated it to the latest tag that builds locally.
The test-file-operations-move-files and test-file-operations-copy-files
test cases randomly crash with "GLib-FATAL-CRITICAL: g_source_is_destroyed:
assertion 'g_atomic_int_get (&source->ref_count) > 0' failed", which causes
GitLab CI pipeline failures among others, which is a shame.
I am not able to reproduce those crashes locally, so I can't easily verify
the call stack, but only place where `g_source_destroy()` is called is
when handling progress infos. I see two potential issues which might cause
this. Let's try to fix them.
Conflict dialog doesn't work properly for google-drive files, because
G_IO_ERROR_EXISTS can be returned even if a destination file based on
a basename of a source file doesn't exists. This happens when a destination
directory already contains some file with the same display_name as the
source file has. Usually, display_name is based on filename, but google-drive
is not traditional filesystem and uses unique IDs for files. Although,
google-drive supports multiple files with the same display_bane in one folder,
the copy and move operations behave traditionally and tries to overwrite
existing files with the same title. Let's base the destination file on
display_name for google-drive to fix issues with the conflict dialog.
See: https://gitlab.gnome.org/GNOME/gvfs/merge_requests/58
We're using newly introduced Pango API, but we're not doing a version
check on it. One option is to force a Pango ≥ 1.44.4 dependency; another
is to do a compile time check and only use the new API if we're building
against a new enough Pango.
After a conflict dialog response, Nautilus accesses an already released
structure, which causes crashes for some people. Let's store pointer
before releasing the structure in order to prevent the invalid reads.
Fixes: https://gitlab.gnome.org/GNOME/nautilus/issues/1353
The view can be zoomed in and out by pressing the + and - keys on the
keyboard while holding the Ctrl modifier key.
However, pressing the look-alike + and - keys from the numeric keypad
doesn't work as an alternative, as one would expect.
Add these keys as alternatives for the zoom shortcuts, like GtkScale
and GtkTreeView already do in similar cases.
Closes: https://gitlab.gnome.org/GNOME/nautilus/issues/1349
"Frames per second" string in audio-video-properties tab was unavailable for translation.
To fix this, handle the string with g_dngettext() and allow for both singular and plural translation.
Closes https://gitlab.gnome.org/GNOME/nautilus/issues/990
When trying to connect to a machine in which server application is not
installed or is inactive, nautilus shows a "Unhandled message error:
Connection refused by server" message.
The message is unhelpful, and there is no reason not to handle this case.
So, handle the error and the give possible reasons for it.
Closes https://gitlab.gnome.org/GNOME/nautilus/issues/855
Tracker uses list of stop words which are not indexed. Consequently,
fts:match doesn't provide any results for such words, which also affects
filenames. I am conviced that this is not crucial issue for content
search, but it is really problem in case of filename search. We should
really always find files regardless of stop words in their names. This
can be fixed on Nautilus side by splitting the search string and using
ftp:match only for content search.
For example, currently it is not possible to find "file-name.txt" file
using "file-n" search string, because "name" is stop word, but it works
nicely with this fix.
Just note that /org/freedesktop/tracker/fts/ignore-stop-words setting
needs to be changed to fix this issue for content search as well.
Currently, snippet contains also filename in case of the filename match,
which is not ideal as it just duplicates the information in UI. With
this change, the snippet is set only in case of the content search.
Pango 1.44 got the ability to automatically hyphenate on line breaks,
which is on by default, but can be set off by a new attribute.
As a result, we now hyphenate filenames, which is confusing, because
a filename may already include hyphens.
To restore the previous behavior, let's not insert hyphens when
breaking filenames in multiple lines.
Closes https://gitlab.gnome.org/GNOME/nautilus/issues/1177
The prefix is not localized, and tends to ellipsize the name.
With the introduction of an icon for the development profile, there is
enough visual distinction in the app grip.
So, drop the prefix.
Part of https://gitlab.gnome.org/GNOME/Initiatives/issues/12
