If org.gnome.nautilus.list-view use-tree-view is TRUE, folders can
be expanded, which creates a dummy row to display the "Loading" label.
The code to display the correct star icon assumes each row represents a
file, but the dummy row breaks this assumption, crashing nautilus when
checking if the NULL file is starred or unstarred.
Instead, don't set a star icon unless the row represents a file. Also,
do nothing if the cell is clicked on a dummy row.
Fixes: #105
If org.gnome.nautilus.list-view use-tree-view is TRUE, folders can
be expanded, which creates a dummy row to display the "Loading" label.
When displaying search results as a list, we look for the fts_snippet
on every row's NautilusFile, but this causes a crash when a dummy row is
created, because its NautilusFile is NULL.
Therefore, we should not look for fts_snippet on dummy rows.
Fixes: https://gitlab.gnome.org/GNOME/nautilus/issues/54
If org.gnome.nautilus.list-view use-tree-view is true, folders can be
expanded. While loading expanded folders, there is a dummy row with
"Loading" label, which turns into "Empty" if no items are loaded. This
row has a NULL NautilusFile.
The code to display the correct star icon assumes each row represents a
file, but the dummy row breaks this assumption, crashing nautilus when
checking if the file is starred or unstarred.
Instead, don't set a star icon unless the row represents a file. Also,
do nothing if the cell is clicked on a dummy row.
Fixes: #105
There are chances that providers get to finish before all are
added, resulting in early calls to check_providers_status() which
mess up refcount. Bumping providers_running early prevents that
to happen.
"open item location" action from 'recent files' view was not
revealing (selecting and scrolling to) the item whose location
was opened.
Selection code logic on canvas/list view compares NautilusFiles's,
so we need to provide one that refers to the destination uri
(activation uri) instead of the original one from recent view which
has a "recent://" uri scheme.
https://bugzilla.gnome.org/show_bug.cgi?id=784516
Fix crash caused by commit 3aba356a when switching to
search view. Crash occured because of timeout being
executed for a destroyed view. So we now save timeout id
to make sure we remove timeout when its view it's being
destroyed.
https://gitlab.gnome.org/GNOME/nautilus/issues/73
If a file named "foo.bar" is duplicated, the copy is named "foo (copy).bar",
keeping the extension at the end.
However, this is applying to folders too, where we don't need to worry about
keeping extesions at the end. The result is unexpected.
Therefore, ignore extension if the duplicating item is a folder, except if the
folder already has a copy tag before a dot, such as "dir (copy).dir".
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=696451
If file type is known but doesn't match any basic type, then it's not unknown.
To fix, call it "Other".
Note that nautilus_file_get_string_attribute_with_default uses "Unknown" as
the default pretty value for NULL.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=758692
Eventually we want continuous integration based on flatpak-builder,
but for now use a Fedora docker image. Do not run the test suite for
now, as some of the tests require access to the display server and
we'll still need to figure out how to provide that ...
We should not sort directories first on search results, as per the
previous commit.
However, on list view, this is checked at init, before a location is
set. We ignore if it is a search directory, as a result, we respect the
setting to sort directories first.
Instead, we will check it later, before loading the contents, when we
already know if it is a search directory or not.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=699629
Search results are sorted by search relevance, which, among other
parameters, ranks results from the current directory above results from
subdirectories.
However, if sort-directories-first gsetting is TRUE, a directory found
deeper in the hierarchy may be ranked above a file from the current
directory. Also, as more directories are found, files keep moving down.
Therefore, we should not sort directories first when searching.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=699629
Instead of setting whether the search should be full text search or
not from the preference dialog, make the permanent setting from the
search popover.
https://gitlab.gnome.org/GNOME/nautilus/issues/65
Currently files which have been edited in the future will show only the
time in the "Modified" field of the file view. This is misleading as it
makes it seem it was actually last touched today. This change means a
fuller datestamp will now be shown.
