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.
File opened in recent tab now is read-only
when it is writable.
Replace nautilus_file_info_get_uri ()
with nautilus_file_info_get_activation_uri ()
fix the problem.
https://gitlab.gnome.org/GNOME/nautilus/issues/378
Originally introduced in commit e7aa2e757c,
this function used to be a lot more complex, but now it is just a
shorthand for nautilus_file_is_mime_type (file, "text/plain").
Its only use was when launching script files on activation.
Since the settings schemas no longer contain the required settings,
opening the preferences window causes an error and a call to abort().
This can be reverted if the ability to launch scripts is reintroduced.
It's often the case that an MR will be opened and call for testing or an artifact will be linked in an issue.
But by the time people review the changes or try to test it them, the provided bundle will be already gone.
In the early days of the gitlab migration the expiration was commonly set to a small interval to ease the transition and not eat up the resources of runners. This should no longer be required going forward and the expiration date can be more flexible.
