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
Name variables are mostly used in quotes.
However, there are a few strings used without quotes, which may cause
a burden for users as the name might be interpreted wrongly.
- renamed assets from generic devkit names to nautilus specific names
- updated folder-search, external-link and cancel-operation with newer assets
- added network-computer symbolic for future use in the sidebar
Almost all basename variables seem to be used in quotes.
However, there are a few strings used without quotes, which may cause
a burden for users as the basename might be interpreted wrongly.
Set correct icon and remove tooltip for cancel
button when an ongoing operation is canceled
Use cancel button icon "emblem-ok-symbolic" instead of
"object-select-symbolic" since it is more correct in the current
use case as suggested by @snwh
Use tooltip "Completed" for cancel button instead of
"Operation Finished" since it is more friendly in this context
suggested by @snwh
Set "Completed" as a translatable string credit to @coreyberla
Part of https://gitlab.gnome.org/GNOME/nautilus/-/issues/3294
If the location changes away from a search directory (other than by
toggling the slot.search-visible action) the view keeps holding a
reference to the search query instance.
This can be picked up by global search later, which then reuses an
old query unexpectedly. The simplest way to reproduce this bug is to
type to search, then select a different location from the sidebar,
then click the global search button.
Let's clear the query whenever the location changes to a non-search
directory. Also avoid property notifications if it was already NULL.
Since the tight relation between between set_search_query() and
location loading is easy to miss and get wrong, also add a few
comments at relevant places where its called.
We have been ignoring clicks on the sidebar item which corresponds to
the current locations, in order to avoid refreshing the view when
something is selected.[0]
However, this bug has been recently fixed in a more effective way by
commit 2b5321660f
Stop ignoring these clicks, because we need to know about them in
order to cancel global search.
This effectively reverts the following changes:
* commit 328cbdde47
* commit 7c760d4bf9
[0] https://gitlab.gnome.org/GNOME/nautilus/-/issues/2960
These floating buttons conflict with floating status bar and their
implementation is glitchy. Also, with the introduction of the global
search mode, the new design guidance asks for their removal.
Instead, allow the new global search action to reuse the existing
local query but run it anew with a global scope.
The "Search Everywhere" button on empty local search results page
is preserved, but made to perform the exact same action.
This effectively reverts commit 67194751aa
In global search mode, history and folder search buttons are hidden.
This causes the searchbar moves to expand its width because a hidden
widget doesn't allocate space.
This resizing of the search entry is obviously undesirable.
As a workaround, don't toggle GtkWidget:visible but, instead, use
a stack to swap the buttons for an empty box to act as their shadow.
The homogenous stack ensure the button alocated space is preserved.
This custom style makes the Search Settings buttons look insensitive.
Let's just use default status page styling.
This effectively reverts commit d4d3902dbd
As per design mockups. The search original icon is going to be used for
a new button which opens the global search mode, and as a prefix icon
is that mode.
Also update tooltip accordingly.
For the global search mode we are going to need to cover contents,
including location banners, with a status page.
We currently derive from a box, and GtkStack is final, so instead
derive from AdwBin, have its direct child be a stack, then add a
vertical box to the stack.
We have code which tries not to hide the search entry in case the user
opens it and, before inserting any query, decides to switch location.
This was introduced by commit 9ab3c5c7d7
According to that commit message, it was restoring an old behavior that
was lost during a refactoring. I did not confirm this nor track the
original reason for this behavior, but, if I had to guess, I'd say it
comes from before "just-type" search was introduced. Otherwise, why go
to the trouble of keeping the search entry visible when you can just
type anyway?
I see no reason to assume the location change means they want to search
another location. They may have just recalled the exact path they were
looking for, so they lost the reason to search.
Anyway, this behavior is not working at all in recent versions. Not
sure when it stopped working, but apparently nobody has missed it.
Least this dead code interfere with the upcoming global search mode,
let's remove it.
