| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
With the introduction of ::extra-drag-value in AdwTabBar, we can
now dynamically set the preferred action on the AdwTabBar. Use
the "extra" drop target on the AdwTabBar, and use our existing code
making this fairly simple.
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/2495
|
|
|
|
|
|
| |
window-slot-dnd never the same makeover as list-base. Reuse existing
code in nautilus-dnd and eliminate all of the unused code for when
nautilus-window-slot-dnd handled tab drop targets
|
| |
|
|
|
|
|
|
|
| |
In gtk4 we aren't using nautilus_files_view_handle_uri_list_drop()
because the uri-lists are handled by gtk now. We did have a dialog
to warn users when an invalid drag was used, instead of passing a
potentially bad GdkDragAction to nautilus_files_view_copy_move.
|
| |
|
|
|
|
| |
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/1620
|
| |
|
|
|
|
|
| |
Add the ability from the tab menu to close all
other tabs.
|
|
|
|
|
|
| |
New tabs are always taking the location of the current tab even
if the new tab was generated from a non-current tab using the
tab bar context menu.
|
|
|
|
|
|
| |
New tabs open up relative to the selected tab. Make new tabs
open up relative to the tab in which the context menu was opened
if applicable (otherwise open relative to the selected tab)
|
|
|
|
|
|
|
|
| |
This isn't a problem now but would cause problems with the
following commits
Return early so we don't set incorrect actions when the
callback passes a NULL page on close.
|
|
|
|
|
| |
Refactoring existing code to simplify, this will help with the
following commits. No logical or functional changes.
|
| |
|
|
|
|
| |
Use of this action was removed in 4ca63d19eb3e522eea54a92c0f479911e2a17f4a
|
| |
|
| |
|
|
|
|
|
|
| |
Also make sure that all of the parameters are gsize
which already matches what we get (strlen returns
size_t). g_memdup took a guint.
|
|
|
|
| |
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/1022
|
|
|
|
| |
This reverts commit 7605b17b2757fa3331f2551c04208e833cd723e1.
|
|
|
|
|
|
| |
After the last few commits, it's clear we no longer distinguish
the metadata strings from the attribute strings, so it's best to
call it "sort attribute" to clarify this expectation.
|
|
|
|
|
|
| |
The adopted solution is not a workaround, it's a documented solution.
https://gitlab.gnome.org/GNOME/gtk/-/issues/4696#note_1578957
|
|
|
|
| |
This simplifies things a little bit
|
|
|
|
|
| |
Keeping this separate to clean the diff. We were missing
"starred" in SortConstants.
|
|
|
|
|
|
|
|
|
| |
The sort type persists for any of the sort orders that are associated
with a NautilusFileSortType enum, but other sort types don't persist.
In update_sort_order_from_metadata, don't rely on the SortConstant
(which reverts back to "name") use the metadataname directly.
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/2688
|
|
|
|
|
| |
We used a sort attribute "unknown" before we had GtkColumnViewSorter.
We dont' need it anymore.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Historically, the strings saved as metadata for per-folder sorting have
been different from the attribute identifier strings.
However, we have been saving the attribute string as metadata since commit
a653ed59ec0e636c4767f0a5341d781f457ddbd2
As we have already broken compatibility with old metadata strings anyway,
let's simplify our code and save our sanity by assuming the saved string
is the attribute string.
|
|
|
|
|
|
| |
Rather than looking up the NautilusColumn from the factory, to get the
attribute of the column sorting, just grab it the newly-introduced
GtkColumnViewColumn:id property.
|
|
|
|
|
| |
The logic is very similar to before, but we don't have to rely
on our hack of grabbing the last GQuark sort attribute used.
|
|
|
|
| |
This reverts commit c72e6def48e47454d4b620f58c93753a8a1b6a3f.
|
|
|
|
|
|
|
| |
Allow pasting raw images from the clipboard to a file within
Nautilus. We just get the raw data, so generate a filename
automatically. Just as with other copy operations, the select
the file after creation.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Copying / pasting within Nautilus is always handled by NAUTILUS_CLIPBOARD,
but sometimes, copying outside of Nautilus may pass a G_TYPE_FILE or
GDK_TYPE_FILE_LIST. Now that the clipboard handling has been
simplified we can accept these other types.
Issue 540 is actually an issue related to G_TYPE_FILE, not the image
itself.
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/540
|
|
|
|
|
|
|
|
|
| |
The clipboard handling in files-view (and list-base) is centered
around NAUTILUS_CLIPBOARD which handles our needs locally, but
does not allow for flexibility around non-local types
(namely G_TYPE_FILE and GDK_TYPE_PIXBUF). It's going to be
very hard / messy to make this work with new types, so let's
re-work the code to be more straightforward.
|
|
|
|
|
|
| |
Share more code between paste, paste into, and paste as link.
This will allow a more straight forward clipboard handling code
|
|
|
|
|
| |
Use AdwWindow as a base class for the conflict dialog, as GtkDialog is
deprecated with GTK 4.10.
|
|
|
|
|
|
|
| |
This is what happens when trying to rename a file that's open on Samba
shares.
Closes: #2570
|
|
|
|
|
|
|
|
|
|
|
| |
G_IO_ERROR_INVALID_ARGUMENT was not handled when renaming a file on a
Samba/CIFS share, using invalid characters.
As this behaviour is very similar to what happens when using an invalid
character on vfat or exfat filesystems, merge it into the
G_IO_ERROR_INVALID_FILENAME case.
See https://en.wikipedia.org/wiki/Filename#Comparison_of_filename_limitations
|
|
|
|
|
| |
Move FAT_FORBIDDEN_CHARACTERS to a header so it can be used in more
places.
|
|
|
|
|
|
|
| |
As advised by HIG, phrases that have only one sentence don't need to end with a period:
https://developer.gnome.org/hig/guidelines/writing-style.html#periods
This commit drops the period.
|
|
|
|
|
| |
This is part of an initiative to use the "app" term instead:
https://gitlab.gnome.org/Teams/Design/initiatives/-/issues/123
|
|
|
|
|
|
| |
Don't allow empty or null names. While the previous commit probably
prevents the symptoms, adding empty or null names is useless and
potentially problematic.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In version 42, we relied on GTK 3's support for GEmblemedIcon to draw
emblems. It would implicitly skip any emblem name for which there was
no available icon:
gtk/gtkicontheme.c:
```
emblem_info = gtk_icon_theme_lookup_by_gicon_for_scale (icon_theme, emblem, size / 2, scale, flags | GTK_ICON_LOOKUP_FORCE_SIZE);
if (emblem_info)
info->emblem_infos = g_slist_prepend (info->emblem_infos, emblem_info);
```
But GTK 4 dropped support for GEmblemedIcon, so now we use one GtkImage
for each emblem. But we don't skip name for which no icon is installed.
Instead, GTK displays the missing image icon.
Let's check whether the emblem icon is available in the current theme
before creating a GtkImage.
|
|
|
|
|
|
|
|
|
| |
The old canvas expanded filename over the next row when the item was
selected. This is impossible to replicate in GtkGridView due to the
next row getting drawn after (== on top of) the previous one.
This is perceived as a feature regression. So, let's aleviate it
using tooltips when the filename is ellipsized.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, thumbnails are not shown for MTP/GPhoto2 locations. The
backends return `G_FILESYSTEM_PREVIEW_TYPE_NEVER` in order to prevent
thumbnailers to make them unresponsive. However, the backends provide
preview icons for some file types and the `GnomeDesktopThumbnailFactory`
is smart enough not to invoke thumbnailers if the icon is available
(see https://bugzilla.gnome.org/show_bug.cgi?id=738503). Let's allow
the thumbnail generation from the preview icons if they are available.
This should not affect backend responsiveness much.
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/1921
|
|
|
|
|
|
|
|
| |
This reverts commit edc2d4ba20252c22dc3645b8e0173dbcd58ac9e9.
This is possible because of enhancements in GTK.
See: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/5374
|
|
|
|
|
|
|
|
|
|
|
|
| |
Nautilus does not persist the window maximized state.
This is because we are listening to the property is-maximized for
change, which is now maximized in GTK4.
https://docs.gtk.org/gtk4/property.Window.maximized.html
Use notify::maximized instead of notify::is-maximized.
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/2682
|
|
|
|
|
| |
Now that the tracker miner fs connection is async we have to set it
proactively or the test fails.
|
|
|
|
| |
We have a better version, if inside_flatpak(), lets use that instead.
|
|
|
|
|
|
|
| |
Now that we have tracker connecting in an async fashion, let's
proactively connect to tracker when the application is launched.
We pretty heavily rely on tracker so there's a good chance we'll
be connecting at some point anyways.
|
|
|
|
|
|
|
|
|
| |
Blocking on a sync connection to tracker on demand creates a noticeable
delay under normal circumstances and can be very problematic when
tracker is not responding. Create the connection async, worst case
scenario the connection is not ready, and then we fall back to our other
search engine providers. Unless tracker is broken anyways, that is
pretty unlikely.
|