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 4fc8812040)
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.
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.
