Since we have to handle the event in reverse order (because GtkTreeView
claims the event sequence in the capture phase, meaning that the events
won’t bubble up), the context menu for notebook tabs will open
everywhere, because the event handler is not stopped by those lower in
the hierarchy. A simple check if the cursor is on a tab will prevent
that.
GTK+ 4 no longer has the fine-grained signals and vfuncs for various
events. Additionally, the scroll_event override in NautilusFilesView
doesn’t seem to be ever called, so this commit removes it.
This is kind of a hack, but we can still use
gtk_style_context_get_color() to get the color of the pie slice. Two
hacks, in fact, as this adds a separate style class to hold the color of
the border.
In theory, it would be possible to just drop the GAIL code and keep the
header, but, given that NautilusCanvasItem is the only remaining
consumer, the needed bits can be moved over.
This is one of prerequisite steps to take before fully switching to GTK+
4, as gnome-desktop has code, depending on GTK+ 3. Since the
thumbnailing machinery is self-contained, it can easily be just copied
over.
The "Parent folder" label is displayed for multi-item properties
in Trash, alongside with the "Original folder" label.
The "Parent folder" label shouldn't be displayed since there is
another label for trashed items and the informations displayed
by it are useless for this kind of items.
Closes https://gitlab.gnome.org/GNOME/nautilus/issues/417
The File Properties Dialog provides too little information for files in
Trash. An example for this problem would be not being able to distinguish
between two files with the same name in Trash.
Add "Trashed on" and "Original folder" labels to File Properties window
for trashed files.
Closes https://gitlab.gnome.org/GNOME/nautilus/issues/417
Although nautilus allows opening files from Trash, properties
window doesn't show "Open with" option.
This patch solves this by adding "Open with" option in the
properties window of trashed files.
Closes https://gitlab.gnome.org/GNOME/nautilus/issues/432
Currently there is a menu which allows changing the permissions
for trashed files.
This is unintended behaviour since changing the permissions for
trashed files is not supported anyway, resulting in an error
message or even Segmentation Fault.
This patch solves this issue by removing the permission access
menu for trashed files.
Fixes https://gitlab.gnome.org/GNOME/nautilus/issues/432
Recently we removed the ability to launch binaries and scripts in
commit 3a22ed5b8e.
A few cases appeared that we need to support, specially for enterprise
and content creators. Specifically, cases similar to https://gitlab.gnome.org/GNOME/nautilus/issues/434
This also shows that is hard to predict cases like these, as some
complex setups might be needed for specific workflows.
This commits allow to run binaries and scripts as before, and further
investigation in these cases need to be done if we ever want to tweak
the workflow of running binaries.
More discussion about improving binaries/script handling is being
proposed and discussed in https://gitlab.gnome.org/GNOME/nautilus/issues/443
This is a reworking of a long standing Ubuntu patch that publishes
the set of locations open in each Nautilus window. The motivation
for this change is that a desktop environment providing special
icons for things like removable devices and the trash can match
windows to those icons for highlighting purposes.
In the original incarnation, Unity provided these icons. In today's
world, I'm maintaining a set of patches for dash-to-dock/ubunut-dock
that provide these icons too.
The original implementation uses Xids to identify windows, but Xids
aren't a thing in Wayland so this mechanism is a dead end. Instead,
we can use the 'gtk application window object paths' which are
published over dbus by GtkApplications, including Nautilus.
Mutter already detects these, and makes them available on MetaWindows.
The original patch added the mapping property to the fileManager1
interface, and I have left that part as-is, but it's likely not to
be the right place to put it. fileManager1 is a generic interface
and a property that assumes a GTK behaviour doesn't seem right.
We could obviously add it to a new interface under org.gnome.Nautilus,
but this would be Nautilus specific - although there isn't a huge
scope for other file managers to implement this property, so perhaps
that's just fine.
dash-to-dock discussion is readable here:
https://github.com/micheleg/dash-to-dock/pull/677
Currently using the [Ctrl]+[F] keyboard shortcut toggles the search bar
visibility.
Using the [Ctrl]+[F] keyboard shortcut shows the search filter popover
(and gives it keyboard focus).
To add this a new action "search-visible-popover" is added which in addition
to the "search-visible" action adds the feature to focus and show the search
dropdown menu.
https://gitlab.gnome.org/GNOME/nautilus/issues/333
When a file is renamed if the name entered by user has a length that
exceeds maximum limit then it shows a window with a warning.
The problem is that once the user has acknowledged the warning, the file
name goes back to its original name. The user is not given a chance to
make slight modifications in the name that was entered.
To fix this problem, a warning will be given in the popup itself where the
new filename is entered. That way the user will be able to make slight
changes so that the file name is within the size limit.
https://gitlab.gnome.org/GNOME/nautilus/issues/148
This commit removes redundant header inclusions and tries to optimize
headers by using forward declarations of types in headers. Such
optimization should generally make builds speedier in that changes in
certain headers will not cause unrelated sources to be rebuilt.
This will save some time/thinking when running tests manually.
G_TEST_BUILDDIR and G_TEST_SRCDIR will be useful if
g_test_build_filename() is ever used, since our primary build mode is
outside the source directory, which would break the function.
