Unmount and eject are already doing this since commit 80dd8fb8ff
Let's do the same for mount and stop, and use g_autoptr() to emphasize
the callback taking ownership of the reference passed to the method.
Otherwise, nautilus_file_can_unmount() will still return FALSE for
a file which is already mounted, until the can-unmount attribute
is updated asynchronously by the file monitor.
This is needed for the next commit to be able to check whether
unmount is possible as soon as the mount operation completes.
We have barely been exposing to these file types since the Computer and
Network places were replaced by Other Locations.
Now that NautilusNetworkDirectory brings them back into use, we need
to account for their special status.
Both mountables and shortcuts to folders open in view, acknowledge it.
And use mountable target URI (if available) as its activation URI.
GBookmarkFile doesn't provide an asynchronous loading API. Given how
GtkPlacesView has always been doing it in the main thread, I suppose
it's fine.
Still, least it cause some delays, let's do it on idle.
For the purpose of these functions, there is no need to set up a file
monitor, nor for the NautilusRecentServers object at all. But they are
provided here to keep context and reuse server_list_load().
The network address bar is going to be adding servers to the list,
while the upcoming network view is going to allow to remove them.
These used to be displayed in a popover attached to the address entry
in the old Other Locations view.
The new design asks for them to be provided in-line with other items
in the view.
As such, reuse and expand the recent servers code to produce GFileInfo
models for the NautilusNetworkDirectory to create new virtual files
from. Unlike the virtual files aggregated sourced from the network:///
and computer:/// GVFS backends, these virtual NautilusFiles have no
corresponding GVFS presence, and are entirely "nautilus-land" files.
Big credit goes to the people who designed the nautilus directory and
file abstractions with this in mind.
The new design for Network view uses an address entry bar which is
similar to the one from Other Locations view. Instead of reinventing
the wheel, let's salvage some code.
In addition to formatting the code to nautilus style, this also makes
a couple of visual changes to match the design requests.
https://gitlab.gnome.org/GNOME/nautilus/-/issues/2785
Now that NautilusPlacesView is gone, we don't use this anymore.
But there is quite a bit of recycleable code here. So, let's take this
out of the build pipeline in order to disassemble it freely.
It's going to be replaced with a new Network view.[0]
For now this removes only the direct support in nautilus code proper.
The code imported from GtkPlacesView is kept to be recycled for a new
purpose.
[0] https://gitlab.gnome.org/GNOME/nautilus/-/issues/2785
In [1], a frame and an overlay were introduced for the redesign of the
thumbnail editor so that the new edit and clear buttons will not be
entirely inside the image frame. This was inside a GtkStack with
another a image which caused it to be scaled since the stack enforces
size homogeneity by default. This is undesirable, so disable it.
[1] 1c70bab1f0
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/3422#note_2128815
The whole application freezes the first time `x-network-view:///` is
visited during a session (or after `killall gvfsd-network`).
This happens because GDaemonFile makes sync DBus calls to mount the
`network:///` location when we call `g_file_monitor_directory()`[0],
which is done by the view when the ready callback is invoked.
In order to avoid this, ensure the `network:///` location is mounted
before invoking the ready callback for the `x-network-view:///` file.
(This achieves a result which is similar to accessing `network:///`
directly, or any other location which is slow to mount: the location
is not changed until after the mount succeeds. I don't think this is
good UX, but it's an entirely different problem which is not specific
to the Network view at all.)
[0] More context on https://gitlab.gnome.org/GNOME/gvfs/-/issues/455
This aggregates files from two sources:
* network:// for discoverable network resources
* computer:// for remote mounts and volumes
For the second case, we need to filter out local mounts and volumes.
For the time being, this is implemented by relying on the the icon
names, until a new file attribute is provided by GVFS.
Instead of special casing the NautilusFile for the starred:/// URI,
give it a proper display name as part of a new specialized subclass.
This is prepared to handle more cases, like the upcoming Network view.
Similarly to .get_date(), addressed by the previous commit, this has
been added for the sake of NautilusTrashFile[0] for it to say it lives:
"on the desktop"
We have no desktop anymore. NautilusSearchDirectoryFile is not on
desktop nor in any view, and it doesn't have a parent, so it doesn't
need this either.
[0] commit d23bb1b5be
It was born as a virtual method with 2 implementations: NautilusVfsFile
and NautilusTrashFile: commit e82bab8c49
Nowadays only the NautilusVfsFile implements it anyway, so, rather than
leaving it undefined for other subclasses it's best to move the
implementation to the parent class and drop the vfunc.
An undefined virtual method obviously can cause problems. A crash
can be reproduced through FileManager1 D-Bus method ShowItemProperties
with the parameters (["x-nautilus-search://0/"],""). We are lucky this
probably never happens under regular usage.
There is no reason for nautilus-directory.c to include the header for
a subclass just to implement a virtual method the subclass could have
implemented itself.
So, have NautilusSearchDirectory create NautilusSearchDirectoryFile
and stop including unneeded headers in directory.c.
Also do precondition checking in the method, not the implementation.
This sets a pattern for upcoming new NautilusFile subclasses.
We always call nautilus_file_set_directory() right after creating the
object, and a file is not expected to live without a directory.
Therefore, it makes sense to require the directory to be passed upon
object construction.
This is not just about adopting idiomatic GObject patterns: it's
going to become useful later for new file subclasses who will need to
know something about their parent directory upon construction.
In [1], global search was excluded from skipping the reloading of
the view like normal search in order for the current content of the
view to not appear in the global search for a short time until the
results were loaded. This causes global search results to flicker
for every key stroke.
Instead, make the condition more specific so that it will not
affect loading between search queries.
[1] ce47e61372
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/3403
We want to use a warning icon to warn about broken bookmarks,
i.e., bookmarks whose pointed path is gone.
But for non-local files, this may just mean they are not currently
mounted or temporarily innaccessible, not necessarily broken.
So, apply the broken bookmark icon logic to native icons only.
Fixes https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/1430#note_2069827
The usage of goto's makes get_native_icon() unnecessarily complex and
error-prone.
Indeed, the goto's may be the reason why the commit[0] which introduced
the `nautilus_bookmark_get_xdg_type()` function as a replacement for
`nautilus_file_is_user_special_directory()` didn't remove the obsolete
checks `bookmark->file == NULL` and `xdg_type < G_USER_N_DIRECTORIES`.
Simplify and modernize `nautilus_bookmark_get_xdg_type()` as well, to
make it clear it the passed `GUserDirectory` value is always lower than
G_USER_N_DIRECTORIES, because it's the for loop condition.
[0] commit 1dcd2d816a
In the following commits we will be dropping gtkbookmarkmanager and
using nautilus-bookmark/list instead. In order to allow renaming
bookmarks we need access to set_name.
