We add mounts to the sidebar in the following order:
* First, those belonging to drives; this ensures physical devices
are prioritized.
* Second, those belonging to volumes (e.g. GOA accounts)
* Lastly, other mounts (i.e. unusual stuff)
While the first two are added to the "MOUNTS" section, in the same
order, the last group is added to the "COMPUTER" section (the one
with Recent, Starred, Home, user dirs and Trash).
This has been working like this since the 3.0 sidebar redesign,
all the way back in 2010: a59e586adf
That commit refers to a long-gone wiki page, but, regardless, I
have reasons to believe this was not intentional:
* the COMPUTER section comes before the MOUNTS section, this means
whe unusual mounts effectively get sorted before the other mounts,
which runs counter to the effort put into adding them last;
* it just doesn't make sense to group mounts with the first group,
which has always been supposed to end with Trash in every mockup
I've seen in since 2010.
* given how unusual these rogue mounts are, such a mistake could
easily have been kept around all these years.
* the COMPUTER section has translated names which we do not want to
ellipsize, but mounts can have arbitrarily long names we do want
to ellipize.
As such, let's just add them to the mounts section, after the others.
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/3291
landlock is set to auto, but that causes our pipelines to fail because
when landlock.h is detected, but is disabled in the kernel, the build
errors. The suggested route is to use explicit build options.
Related: https://gitlab.gnome.org/GNOME/tracker-miners/-/merge_requests/508
We've been emitting it only when the first new item arrives.
This happens at process_pending_files().
But if no file every arrives, the previous items are never
cleared. This happens when opening an empty folder from search
results.
So, unconditionally emit the delayed signals before calling
provess_pending_files().
Fixes https://gitlab.gnome.org/GNOME/nautilus/-/issues/3302
This improves performance with directories that have a large number
of direct descendants. Also use the words 'unsatisfied' and 'ready'
instead of active and inactive to better describe the two types.
Simplify ordered comparision function into equality since it's not
being used as ordered comparsion. Keep the name to imply that
it still treats 0 as an equal, same as GCompareFunc.
Most of the time, the functions end up looking up the parent file
twice. So reuse the parent file by passing it directly to improve
performance when loading many files. This roughly improves
`get_speed_tradeoff_preference_for_file` by about 40% when having
local thumbnails only preference, which is by itself about 10%
of CPU time of loading large directories before this optimization.
There's no reason for this to be restricted to directories. it was
introduced in [1] which seems to just copy the logic from [2] which
was meant for `filesystem::type`. I can't find any commit or
documentation change that states it was ever exclusive to
directories though. Also protect the reading with a check to wether
the filesystem metadata is up to date.
[1] 99f55748ef
[2] bfd9ccf65c
Put an upper limit on the number of names added to the properties
window. This improves performance when selecting large number
files. Moreover, it is unlikely for many items to fit in the
allocated text area.
When displaying the properties of a large number of files that are
not nested, an inefficient code cause the dialog to take 100+
seconds to open. Instead of generating the entire list again for
every check, store them in hash table before iterating, and search
using the hash table. This provides extreme time saving factor
with large file count.
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/1726
