The cloudproviders integration used to be part of GTK 3 version, but
it is not part of GTK 4 version. This is because the sidebar codes
are now part of Nautilus codebase and `HAVE_CLOUDPROVIDERS` is never
set. Let's allow to build with cloudproviders support again.
Related: https://gitlab.gnome.org/GNOME/nautilus/-/issues/2392
The new list view is going to be GtkColumnView-based, so it's going to
share some code with the GtkGridView-based view.
In order to avoid code duplication and still keep the NautilusFilesView
class agnostic of the widgets used by final classes, create an abstract
NautilusListBase class.
But this abstract class needs to interact with the item widgets, which
are going to be different between views. To resolve this, an abstract
NautilusViewCell class is created for the item widgets, which is also
going to be used for the new list view column cells.
Also, bump GLib version requirement now that we use GSignalGroup.
This is a follow up from https://gitlab.gnome.org/GNOME/nautilus/-/commit/6af38c29d
As a result of that commit, it's not possible to set a picture as desktop wallpaper
from Nautilus unless libportal is used. Since libportal is generally available,
it's no longer a useful option to not use libportal.
We've deviated from the upstream source enough for this script to no
longer operate.
From now on we should just cherry-pick changes as needed, at least
while we try to stay close to the GTK code.
GPL3+ is a deprecated SPDX identifier.[0] The meson and about dialog say
GPL 3.0, so that should also appear on the appdata.
[0] https://spdx.org/licenses/
The new major version of the toolkit is a requirement to fix old issues and enable future enhancements.
Update symbols and adapt logic to API changes.
Update and simplify UI definitions.
Update local copy of places sidebar and places view.
Replace dependencies with their GTK4-compatible successors.
Make a minimum changes required to build and run, with known
regressions to be fixed in future commits.
For a detailed breakup of the changes, see the 36 commits-deep
log leading to d5763facb1e5045251171ed1273dca0859f3542f.
This is the main part of https://gitlab.gnome.org/GNOME/nautilus/-/issues/276
Build log contains deprecation warnings for gexiv2 functions.
Replaced `gexiv2_metadata_has_tag()` with
`gexiv2_metadata_try_has_tag()` and `gexiv2_metadata_get_orientation()`
with `gexiv2_metadata_try_get_orientation()`
Closes: #2033
Currently, it is not possible to create encrypted archives over
Nautilus. Let's add support for encrypted .zip files to not have
to install a dedicated archive manager.
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/822
The build log contains warnings about deprecated gexiv2 functions. Let's
port to the new API, unpin exiv3 and gexiv2 dependencies in flatpak manifests
and bump the build dependency accordingly to get rid of the warnings.
Nautilus follows this algorithm when copying or moving directories:
1. Create the destination directory.
2. Copy/move the old directory contents recursively.
3. g_file_copy_attributes from the old directory to the new.
4. Delete the old directory.
The issue is that when moving a non-empty directory, step 2 leads to
modification of the old directory's mtime, so g_file_copy_attributes
copies the attributes that were already lost at that point.
This commit fixes it by splitting g_file_copy_attributes into two steps.
It depends on glib!1449.
Closes: gvfs#471
Signed-off-by: Maxim Mikityanskiy <maxtram95@gmail.com>
This means the Nautilus flatpak will be able to use Tracker on systems
which don't have Tracker 3 available on the host. It comes at a cost of
increased resource consumption inside the Flatpak due running an extra
indexer process there.
Mostly the port is straightforward, we connect to tracker-miner-fs
explicitly over D-Bus instead of the centralized tracker-store daemon
we connected to previously.
The search-engine-tracker test is now isolated from the user's real
Tracker index using the `tracker-sandbox` script provided by Tracker,
and it lets tracker-miner-fs index the test file rather than trying
to synthesize the expected database contents.
There are more changes in nautilus-tag-manager.c. Until now, starred
file information was stored in the tracker-miner-fs database. This has
some downsides, firstly the data is deleted if someone runs `tracker
reset --hard`, secondly it isn't possible to do this from inside a
Flatpak sandbox with Tracker 3.0. because the
This commit changes the NautilusTagManager to set up a private
database inside XDG_DATA_HOME/nautilus/tags. This stores the starred
file information. The database is managed with Tracker, which allows us
to continue using the rename-tracking that tracker-miner-fs provides.
The same limitations apply as before that only files in indexed
locations can be starred.
