Now that the views contain real widgets, Tab and Shift+Tab cycle
through every item and only allow leaving the view when at the
end or start of the list, respectively.
This is frustrating for directories with more than a handful of files.
Also, users expect to use arrow keys to cycle though items already.
So, allow to tab into and out of the view, but not inside.
When an item is deleted, focus moves to the next item.
But if the previous item was not only focused by also selected, the
expected behavior is for the newly focused item to also become the
new selected item.
I believe this should be fixed in GtkListBase itself, but let's add
a workaround for now.
Fixes https://gitlab.gnome.org/GNOME/nautilus/-/issues/2489
... and provides a partial workaround for https://gitlab.gnome.org/GNOME/nautilus/-/issues/2489
Calling g_utf8_validate() on a NULL string crashes Nautilus. This
can occur if performing an operation on an invalid file. If
basename is NULL, there's nothing we would do anyways, so just
return early and prevent the crash.
There's a similar issue with get_unique_target_file(), but
if a bad uri was passed to this function it should fail much
earlier, so lets just add an assertion.
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/2376
We have been unconditionally using "media-removable-symbolic" icon,
which is currently representing a USB thumb drive.
This is obviously wrong for any other removable devices, such as
external SSD or HDDs, as well as SD cards.
Therefore, use the mount icon, which is what's shown in the sidebar.
Resolves https://gitlab.gnome.org/GNOME/nautilus/-/issues/2625
We shouldn't be using filesystem::type, which isn't meant for UI, as
discussed in https://gitlab.gnome.org/GNOME/nautilus/-/issues/98
But a proper fix is going to take some time and possibly introduce a
new dependency (udisks2).
So, until we fix that issue, let's workaround the common outrageous
case of a FAT filesystem being captioned as "Msdos filesystem".
https://gitlab.gnome.org/GNOME/nautilus/-/issues/98
It's been added expecting Builder would support it, such that we could
drop the JSON manifest. 3b8f238624
But it didn't happen so far https://gitlab.gnome.org/GNOME/gnome-builder/-/issues/520
Since then we have been maintaining both files in sync, which is a waste
of effort at best, and a risk of the product of each manifest becoming
different, at worst.
Now that the CI uses the JSON manifest, we can just drop the YAML one.
After pasting and selecting "Replace" in the file conflict dialog,
the new files are not selected (or focused). This happens because
in nautilus-files-view, we are waiting for the "add-files" signal,
which never emits because the files aren't added, they are changed.
Set the overwritten files as FALSE in the debuting_files so that
we don't incorrectly wait for "add-files".
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/2669
We are making the assumption that the clipboard data is always
correctly formatted. Given that the "x-special/gnome-copied-files"
doesn't necessarily have a defined specification and that some
other software programs seem to be passing bad data, we need to be
more careful about the assumptions we make.
Let's add a few more checks:
1) The first line must begin with "copy" or "cut"
2) All subsequent lines must either be a valid URI or an empty string
(after stripping out '\n')
3) If there are any errors in the clipboard, return an error rather
than an empty clipboard
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/2539
When nautilus is asked to handle a regular file (e.g. its URI being passed as command line argument),
we open its parent folder and select the file. But for archives, we want to extract them immediately
instead (this is convenient when e.g. handling opening a downloaded file from the web browser).
However, we don't actually extract the archive unless we support are the default handler for that MIME type,
in which case we don't select it as a regular fiel either, which is inconsistent.
So, make sure we only handle archives specially if we actually meant to extract them.
Fixes https://gitlab.gnome.org/GNOME/nautilus/-/issues/2274
It doesn't make sense to change locations onto the same folder you
are dragging from. The easiest way to tell if we are dragging
onto the source drag is when the drag_item_action is set to 0.
This has the added benefit that drag_item_action is also set to
0 when hover over a file. We have been calling
`nautilus_files_view_handle_hover()` unnecessarily on file destination
(which ultimately had no effect).
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/2670
In `nautilus_dnd_get_preferred_action()` we check if the dropped file
and target file are equal, but only after the check if we are dropping
onto an archive. The `g_file_equal()` check if wrapped in a
`dropped != NULL` check which turns out to be unnecessary because
we return in the very beginning when `dropped == NULL`
Move around the drop target action checks to simplify and
prevent dropping anything on itself.
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/2737
In real_set_selection, we call gtk_selection_model_get_selection()
to be able to efficiently update the selection (we don't care about
unselected items that we aren't going to select). That bitset,
per the documentation, shouldn't be modified. This bug (which made
this function effective useless) went unnoticed because we were
setting the selection elsewhere by poking the internals of the
listbase in set_focus_item. We don't want to do that anymore, and
this bug became apparent.
Make a copy of the bitset, and rename the existing bitsets to clarify
what we are doing. Also, set the selection after setting the
focus just in case that ever conflicts in the future.
When moving away from GtkMessageDialog, we forgot this small
program is not part of the main application. [0]
Therefore, we need to initiate libadwaita here, before using any of its widgets.
[0] a80aacdf2c
When moving away from gtk_dialog_run() [0], we forgot this small
program is not part of the main application. So, without anything
blocking the `main()` function, it's going to quit right away, without ever drawing the dialog.
Credit goes to Will Thompson for diagnosing the issue, and GTK
test suit for the while loop solution I've taken from there.
Closes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/2209
[0] d87f5be77b
Since 8978c6375b, `autorun.sh` (but not
`.autorun` or `autorun`) has been run via `/bin/sh`, not executed
directly. The justification in that commit was as follows
> nautilus-autorun-software: Use /bin/sh for autorun.sh execution
>
> If the autorun file is called autorun.sh it is clearly meant for
> execution through a sh processor. The benefit of using /bin/sh as the
> executable is that autorun will also work on FAT formatted media (which
> does not allow autorun.sh to have +x permission set)
However that patch was incomplete. The third argument to _check_file()
is 'must_be_executable'; if set, _check_file() will return FALSE when
the file does not have the executable bit set. It is possible to mount
FAT media in such a way that regular files get the execute bit, but this
is not the default.
As a result, if you place `autorun.sh` in the root directry of a FAT
device, Nautilus offers to run it, but w hen you take it up on that
offer it fails, claiming:
> Unable to locate the program
Complete the special handling of the autorun.sh name by not requiring it
to be executable.
See https://gitlab.gnome.org/GNOME/nautilus/-/issues/2675
We are using a workaround to get the preferred action in x11
where we check the preferred action of the drag. This works for local
drags, but obviously not non-local drags. The workaround is necessary
because of a bug in gtk. Let's just default back to COPY for non-local
drags.
In gtk3 Nautilus used to construct the uri-list.
nautilus_uri_to_native_uri() was used to ensure that apps that didn't
have gvfs access could access the dropped file. Now gtk4 constructs
the uri-list, so a similar process is handled on the gtk side.
Related: #2632
For a very long time, we've been passing NULL as the
parent window to show_dialog() for failed rename
operations. This is in a deeply nested callback, so
rather than trying to pass the window all the way back
just get the current active window, which very likely is
the correct window given how quickly this operation will
fail.
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/1199
Pango library doesn't support specifying text-transform in utf8
codepoints. It instead uses positions in the raw string. This is why we
have problems with, for example, the Cyrillic label in the UI file
text_transform positions are specified as 0 for the start and 1 for
the end and the first Cyrillic letter consist of two bytes.
Remove attributes from the UI file and implement label text capitalization
using the function eel_str_capitalize() which does the same but in
a proper way for type_value_label and type_file_system_label.
Fixes https://gitlab.gnome.org/GNOME/nautilus/-/issues/2494
