Instead of allocating a new list, directly edit the list in the cleanup
function. Query the next list node before potentially changing the list.
Also, inline parameter declarations.
As only one metadata keyword is ever excluded, there is no need for a
vector of excluded keywords. Instead, return early if the exclusion is
not needed and compare with the keyword if it is.
After commit [1], back and forward actions are not correctly
reenabled after restoring a tab. The actions were previously
reenabled after restoring a tab due to the fact that the
restored tab was not automatically active. Once the tab
was created and the user switched to the newly restored tab
that would fire a location change which in turn called
nautilus_window_sync_location_widgets() where the back and
forward actions would get enabled. Now that the actions live
in the slot, this no longer happens. Reenable the actions
after the back and forward lists have been restored.
[1] 2d6f4b8280
The original design for providing search information used a banner,
which does not align with modern conventions. This commit introduces a
new popover to display the same information inside an adwaita status
page
The functionality to check if a directory is indexed was removed in
commit bd30a21a. We need to restore this feature to notify users whether
their folders are indexed when they perform searches within those
folders.
Global preferences for localsearch (formerly tracker) were removed in a
previous commit. To check whether a folder is indexed or not, this
setting is needed.
The is_external_volume function is commonly used and will be useful in
multiple places. Move this function from gtk/nautilusgtkplacessidebar.c
to file-utilities for easy importing
and reuse across different components.
The banner displaying information about the folder being searched is now
redundant. With the introduction of the new popover that follows the
latest design guidelines, the banner can be safely removed.
- Add .warning style class to the feedback and to the name entry
when a feedback text appears
- Add .caption style class to the feedback text
- Use the same top margin from the feedback text of
NautilusCompressDialog
- Remove the bottom margin to avoid triggering an unnecessary
scrollbar
This is going to allow the upcoming FileChooser portal implementation
to attach its window as a modal dialog to client applications, even
if they use different display servers (X11 and Wayland).
If this initialization fails somehow, we gracefully fallback to no
interoperable parenting between X11 and Wayland clients.
Make it a private static library to be used in commming commits.
Contrary to upstream, we use the imported *.impl.* definitions.
For convenience (not to move a lot of meson code around), define
the HAVE_GTK_WAYLAND and HAVE_GTK_X11 in config.h instead of
compiler flags.
These are copied from [xdp-desktop-portal], to avoid adding it and all
its dependencies as buildtime dependencies of our own (and to the
flatpak manifest).
[xdp-desktop-portal]: https://github.com/flatpak/xdg-desktop-portal/
If we are a wayland client and:
- mutter is not patched to allow us to use the ServiceChannel;
- or the compositor is not mutter-based,
We should not even try parenting our dialog over an X11 client,
instead falling back to no parenting at all.
`x11_interop` is the symbol of a global variable, but gets reused for
a local one.
We should try to keep this code in sync with xdp-desktop-porta-gnome
so, instead of chaning the symbol, ignore the compiler error.
This is code copied from xdg-desktop-portal-gnome repository today[0].
We need it to implement the FileChooser portal ourselves.
It's not included in the build yet, as it needs modifications first.
[0] b92a8cc5f6
It's missing a case in get_property() despite being readable. We
haven't been reading it so far, which is why this has gone unnoticed.
But the upcoming FileChooser implementation will read it.
Also, we have been explicitly notifying it, so flag it as such to
avoid double notification. While here, drop obsolete nick and blurb.
The changes notifications on the NautilusView:selection property are
not reliable. E.g. when the view switches to a new location, it
empties the model, which effectively clears selection, but this is
not notified as a selection change.
This happens because we have been incorrectly relying exclusively on
the ::selection-changed signal from the view model. As documented on
GtkSelectionModel, and contrary to intuition, this signal doesn't
notify about changes to the selection set; instead, it notifies about
changes to the selection state of individual items! In other words,
it doesn't notify us if a selected item is removed from the model.
The FileChooser dialog is going to rely on NautilusWindowSlot to get
the current selection. The slot currently caches the selection from
the view. So, we need to invalidate that cache correctly, and for
this we need the view to reliably notify any changes to selection.
The correct way to effectively track changes to the selection set is
to listen to ::items-changed in addition to ::selection-changed.
Instead of reinventing the wheel, rely on GtkSelectionFilterModel to
do the job for us. Then we can just listen to changes in that model.
As it turns out, this is also the correct fix for
https://gitlab.gnome.org/GNOME/nautilus/-/issues/2338 and
https://gitlab.gnome.org/GNOME/nautilus/-/issues/3354
In the future we may want to further refactor our get_selection()
logic around this filter list model, perhaps with GtkMapListModel to
have NautilusFile as item-type, to use proper reference-counted
contained instead of going around doing deep copies of GLists, but
that's for another time.
There is no need to treat this as a programming error. Simply don't
validade filename without a directory.
This is going to be needed by the FileChooser in SAVE_FILE mode, if
neither the client app nor the user has set a target directory yet.
This property is going to be set to TRUE by the upcoming FileChooser.
If turned on, the validator will still provide feedback on duplated
names, but it will accept them nonetheless if otherwise valid. It's
up to the FileChooser to confirm the user wants to replace the
existing file.
Instead of using out parameters and local variables, store booleans
in the instance structure.
This is required to introduce more nuanced behaviors, like allowing
to override existing files on FileChooser dialog.
Instead of reimplementing GtkFileFilter, which conveniently takes
the GVariant format from the FileChooser portal interface, let's
wrap it with a filter of our own which translates NautilusViewItem
into a dummy GFileInfo.
