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.
This is more explicit and convenient than getting a temporary location
reference just to compare it to NULL.
Use it where appropriate. More uses in up comming patches.
Usually, g_dbus_proxy_call() sinks the floating reference for us.
However, if there is an error creating the proxy, we leakit.
Instead of relying on the code calling this API to do the right thing,
let's sink the floating here reference and cleanup automatically.
We have been hitting warnings about NULL queries when doing
global searches, and this was the cause.
There is no good reason not to create a query, even if we are
not going to use it. Fix this before we make global search
more prominent.
We have an idle callback to deal with search text changes while
avoiding performance impact. We also freeze this completely if
the text changes are done programatically and not from user
typing.
But the idle callback is also responsible for hiding the clear
icon, which means we don't hide it if the entry is cleared
programatically (e.g. when leaving search using the Escape key
or the toggle button in the headerbar).
Since there is no performance cost to changing this visibility
of the child widget, we can just move this code to the synch
hanlder, before the change_frozen interrupt.
This conjunction makes no sense and might even lead to NULL pointer
dereference. This bug has been introduced just after the GTK4 port,
by commit 45c77d2466
Just make it a disjunction. This allows the clear button to correctly
hide when the user clear the text.
Commit c653f88090 ("list-base: Don't inherit from NautilusFilesView")
broke our ability to right click on an empty view to open the background
context menu because the list-base is no longer a child of files-view.
We could move the gestures from list-base to files-view, but that's
problematic not only because of the weird hack we use (to deny
background click after clicking on a view item, but also because we
might want to not allow background click (for example in the network
view), and claiming the background click in such a view would
interrupt the gesture for the underlying view (i.e. GtkListView).
So let's take the path of least resistance and just add the gesture
on the empty state itself.
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/3281
A regression in commit d4526131c1 ("filename-util: add conflict
name creation helper") causes an infinite loop when creating a
file (i.e. from template) where the suffix needs to increment.
This also led to an unexpected behavior of causing the first
duplicate to be suffixed with (1) instead of (2).
Pre-increment the counter to avoid the infinite loop and
start a (2).
This may happen when opening item location from results of the same
directory, because location changes (from search to directory) but
the history bookmark doesn't (because search is never a bookmark in
history).
So, explicitly prevent prepending the head of the back list to the
list itself a second time, which duplicates the entry unnecessarily
and generates warnings.
Adding a NULL location to history may happen in a corner case as a
result of search not being added to history anymore. This would lead
to a crash when trying to go back. So, prevent this from happening.
Fixes https://gitlab.gnome.org/GNOME/nautilus/-/issues/3285
The manually started pipelines over the Run pipeline button are currently
blocked. Let's enable them again so one can e.g test Dockerfile changes
without merging them first.
