These actions have been living in the window, but they are actually
implemented by the slot, and conceptually they are slot actions.
Import them in preparation to use them also in the FileChooser window.
Part of https://gitlab.gnome.org/GNOME/nautilus/-/work_items/3413
We do so in two cases: active slot change, or :allow-stop change.
Have the window handle both cases: it is the one who changes active
slot already, and listening to NautilusWindowSlot:allow-stop changes
is trivial.
This resolves a layer violation and is one fewer NautilusWindow
method being called by NautilusWindowSlot, preparing the later for
reuse in the FileChooser portal dialog window.
Part of https://gitlab.gnome.org/GNOME/nautilus/-/work_items/3402
This is used by NautilusFilesView, which is a layer violation. But
it's also useless, because the only thing it does is sync the
start/reload actions, and that's already done by the slot calling
nautilus_window_sync_allow_stop() anyway in the same situations
(i.e. when view starts or ends loading).
Drop it, to prepare the view to be reusable in FileChooser dialogs.
Part of: https://gitlab.gnome.org/GNOME/nautilus/-/work_items/3402
Like the previous commit, this resolves a layer violation and paves the
way for NautilusWindowSlot to be reusable in future FileChooser dialog,
by not using NautilusWindow methods.
On this particular case, we have been updating window widgets which
depend of current location whenever the active lot changes or the the
location of the active slot changes.
On the first case, the window is in charge of setting the active slot,
and in the second case it is already listening to the locatio change.
In both cases, on_location_changed() in nautilus-window.c is called.
So, sync the location widgets from on_location_changed() and stop
exposing it in the header.
Part of https://gitlab.gnome.org/GNOME/nautilus/-/work_items/3402
We rely on the slots calling sync_title() on the window, which is
wasteful (if the slot is not active), fragile, and a layer violation.
We already have properties for all of these pieces, so let's use
expressions. This also helps with preparation for FileChooser window,
as we need NautilusWindowSlot to stop calling NautilusWindow method,
as part of https://gitlab.gnome.org/GNOME/nautilus/-/work_items/3402
We call it to assert the slot being set as inactive is (still) active.
Not only is this counter intuitive, but it also relies on order of
events in nautilus_window_set_active_slot(). Therefore, the assertion
is useless because we already rely on NautilusWindow doing it right.
Instead, make the caller of nautilus_window_slot_set_active() (i.e. the
window) responsible for ensuring consistency. To ensure it is not set
by any other means, make the property read-only.
One less NautilusWindow method being called by NautilusWindowSlot, as
part of https://gitlab.gnome.org/GNOME/nautilus/-/work_items/3402
The slot accesses the window's tab view to change the selected tab.
This is a layer violation, which is both completely unnecessary and
is getting in the way of reusing the slot widget in a tabs-less
window (such as the upcoming FileChooser window).
So, have NautilusWindow manage the selected tab directly. This is
one less NautilusWindow method being called by NautilusWindowSlot.
Part of https://gitlab.gnome.org/GNOME/nautilus/-/work_items/3402
We'v been relying on a gtk_widget_grab_focus() call to avoid broken
focus states after view (re)loading.
But there is one particular case where we must not do it: if the
popover menu is shown. This is a rare situation which is currently
only possible to trigger by pressing [Spacebar] while the "Show
Hidden Files" menu item has focus.
But this currently relies on the slot calling a NautilusWindow method,
which is a layer violation which is getting in the way of reusing
NautilusWindowSlot in the FileChooser window[4].
Let's use generic GTK/GDK API to assess wether the menu is shown,
and drop the NautilusWindow method.
Originally I've just removed the grab_focus() call, but came to
realize it was still needed, so let's also document my findings here.
Part of: https://gitlab.gnome.org/GNOME/nautilus/-/work_items/3402
The selection check is done after the emission of delayed singals which
may change it, as per commit 09f4546d50.
However, nowadays we have a habit of combining declaration and
assingment into a single statement. So, during future hacking, one
might be tempted to move the assignments into the declaration lines,
effectively reverting that commit.
Let's keep declaration and assingment together but after that call,
and also add a comment to make it clear this order is intentional.
We've not been dropping handles properly, and we've been getting
warnings from gdk_wayland_toplevel_real_unexport_handle() as such.
This is because we are passing the "wayland:"-prefixed string, but
the actual wayland export handle is only the part after the colon.
Fixes a regression from commit ad865de618
(cherry picked from commit 4fc8812040520f40ef01f8b016c02018077e4c23)
Add starring and unstarring actions to the pathbar context menu.
In order to disallow starring the home directory, add a new function to
the tag manager, which checks if a given directory can be starred.
If the file is destroyed before the mount operation is completed,
we cancel the mount operation.
However, due to the nature of GAsyncResult, the callback is still
called in a future iteration of the main loop, when the file is
long gone. But since it's passed as callback data, we try to
cast it, with predictably bad results.
Access the file pointer only if the operation hasn't been cancelled.
In the network view, if the row is not selected, clicking the unmount
button does nothing. Indeed, the action is still disabled, despite an
elligible item being selected already.
This happens because the actions state is updated on idle along with
the context menus. This is reasonable as the context menus update can
be expensive.
However, not updating actions state imimediately is unexpected, so
let's immediately update them when selection changes.
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.