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 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: a59e586a

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

This reverts commit e3d7f0b3.

This breaks on 32-bit systems and generally is not very helpful to have.

Fixes #3322

This is a follow-up from d2f2201d

Fixes #3322

Appstream decided to use reversed domains. Please merge before 46 if possible.

Part of https://gitlab.gnome.org/GNOME/Initiatives/-/issues/50

The mutter portion of the comment isn't relavent after [1]
and #1 was resolved in [2]

[1] https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/179
[2] https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/630

When navigating to an invalid location (i.e. through the location
entry, a bad bookmark, etc), the file add/changed handlers are no
longer present in the view until another location change (or reload)
happens.  The existing call to nautilus_window_slot_set_viewed_file()
is not enough to fully reestablish the handlers which were removed from
the call to nautilus_window_slot_stop_loading() (which
ultimately calls disconnect_directory_handlers() in files-view).

There's an explicit comment introduced at [1] which makes it clear
that we want to remove these handlers early for performance and search
reasons. Otherwise we could have delayed removing the handlers which
would have allowed us to not call nautilus_window_slow_force_reload() at
all.  But since this invalid location is just a corner case which
most likely won't happen, let's keep the typical case optimized.

Alternatively, we could create a new function in files-view to
only reconnect the handlers but that too seems to open up a can of
worms for little return.

This bug was introduced in [1]

[1] 9e1e14db

This reverts commit 95f3db44.

As suspected, this isn't enough.  The DnD gestures also need to work
on the empty view.  Revert this fix and in the next commit we'll move
the empty view to be a child (within a stack) of the list-base.

The changes in commit c653f880 ("list-base: Don't inherit
from NautilusFilesView"), broke our gestures on the empty status page
which is still a child of files-view. Rather than attempt to fix this
through files view, as done in commit 95f3db44 ("files-view: Add
gestures to open background menu in empty view"), which fixed the click
gestures, but not the dnd gestures, let's make the more appropriate
change of making the empty status page a child of list-base.

Having the empty status page as a child of the list-base is more logical
because it represents the view, and ultimately our goal is to remove
all view components for files-view (despiste its name).

The empty page is still managed externally, to make it reusable accross
view mode changes. Being an overlay also allows its visibility to be
externally controlled.

Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/3309

(Commit message originally by Corey Berla)

It used to allow changing between regular view and empty view.

(Extracted by António Fernandes from originally larger patch)

Also mark them as translatable.

Fixes #3331

- stylise the whole indicator to be like a sidebar item
- adjust the spacing and padding and pixel-size in the UI file

(Ammended by António Fernandes <antoniof@gnome.org>)

This reverts commit d2b2c814.

This usage of the text cursor is unusual. We should instead explore
highlight on hover.

When debugging, knowing the file uri might be helpful. Generally it is
not helpful though, as it might faciliate users exposing private file
names in bug reports.