summaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* general: Use gobject ADD_PRIVATE macrosCorey Berla2023-01-096-13/+11
| | | | Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/1022
* list-base: Stop referring to "metadata name" for sort attributeAntónio Fernandes2023-01-082-11/+11
| | | | | | 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.
* list-view: Remove incorrect commentAntónio Fernandes2023-01-081-2/+0
| | | | | | The adopted solution is not a workaround, it's a documented solution. https://gitlab.gnome.org/GNOME/gtk/-/issues/4696#note_1578957
* list-base: Use metadata names directly instead of SortConstantsCorey Berla2023-01-083-113/+16
| | | | This simplifies things a little bit
* list-base: Get ready to eliminate SortConstantsCorey Berla2023-01-081-0/+59
| | | | | Keeping this separate to clean the diff. We were missing "starred" in SortConstants.
* list-base: Remember directory sort for all attributesCorey Berla2023-01-081-8/+8
| | | | | | | | | 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
* list-view: Remove "unknown" sort attributeCorey Berla2023-01-081-6/+0
| | | | | We used a sort attribute "unknown" before we had GtkColumnViewSorter. We dont' need it anymore.
* list-view: Drop hardcoded sort attributes arrayCorey Berla2023-01-082-25/+2
| | | | | | | | | | | | 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.
* list-view: Cleanup action_sort_order_changed()Corey Berla2023-01-081-10/+2
| | | | | | 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.
* list-view: Use ColumnViewSorter to save column sortingCorey Berla2023-01-081-30/+51
| | | | | 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.
* Revert "list-view: Keep track of the most recently sorted column"Corey Berla2023-01-081-98/+14
| | | | This reverts commit c72e6def48e47454d4b620f58c93753a8a1b6a3f.
* files-view: Allow pasting GDK_TYPE_TEXTURECorey Berla2023-01-083-4/+178
| | | | | | | 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.
* files-view: Move existing functions for re-useCorey Berla2023-01-081-6/+12
|
* files-view: Allow pasting from G_TYPE_FILE and GDK_TYPE_FILE_LISTCorey Berla2023-01-081-1/+39
| | | | | | | | | | | | 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
* files-view: Re-work and simplifiy clipboard retrievalCorey Berla2023-01-083-94/+88
| | | | | | | | | 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.
* files-view: Add PasteCallbackData structCorey Berla2023-01-081-75/+43
| | | | | | Share more code between paste, paste into, and paste as link. This will allow a more straight forward clipboard handling code
* file-conflict-dialog: change base to AdwWindowPeter Eisenmann2023-01-086-123/+189
| | | | | Use AdwWindow as a base class for the conflict dialog, as GtkDialog is deprecated with GTK 4.10.
* error-reporting: Handle G_IO_ERROR_BUSY on renameBastien Nocera2023-01-081-0/+9
| | | | | | | This is what happens when trying to rename a file that's open on Samba shares. Closes: #2570
* error-reporting: Handle G_IO_ERROR_INVALID_ARGUMENT on renameBastien Nocera2023-01-081-5/+12
| | | | | | | | | | | 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
* file-operations: Make FAT_FORBIDDEN_CHARACTERS constant publicBastien Nocera2023-01-082-2/+1
| | | | | Move FAT_FORBIDDEN_CHARACTERS to a header so it can be used in more places.
* appchooser: Remove the period from the description textsunflowerskater2023-01-081-1/+1
| | | | | | | 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.
* general: Rename "application" to "app"sunflowerskater2023-01-0810-21/+21
| | | | | This is part of an initiative to use the "app" term instead: https://gitlab.gnome.org/Teams/Design/initiatives/-/issues/123
* grid-cell, name-cell: Don't add missing emblemsAntónio Fernandes2023-01-082-0/+20
| | | | | | | | | | | | | | | | | | | | 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.
* grid-cell: Show tooltip for ellipsized namesAntónio Fernandes2023-01-082-0/+23
| | | | | | | | | 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.
* file: Generate thumbnails when the preview icon is availableOndrej Holy2023-01-042-1/+16
| | | | | | | | | | | | | 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
* Revert "list-view: Only insert columns when they should be visible"Corey Berla2022-12-291-15/+28
| | | | | | | | This reverts commit edc2d4ba20252c22dc3645b8e0173dbcd58ac9e9. This is possible because of enhancements in GTK. See: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/5374
* nautilus-window: Fix window maximized notify signalGary Li2022-12-281-1/+1
| | | | | | | | | | | | 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
* test-nautilus-search-engine-tracker: Setup connection proactivelyCorey Berla2022-12-282-0/+33
| | | | | Now that the tracker miner fs connection is async we have to set it proactively or the test fails.
* tracker-utilities: Use existing check nautilus_application_is_sandboxed()Corey Berla2022-12-281-7/+2
| | | | We have a better version, if inside_flatpak(), lets use that instead.
* tracker: Setup miner connection upon application startCorey Berla2022-12-283-3/+7
| | | | | | | 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.
* tracker-utilities: Make tracker connection asyncCorey Berla2022-12-281-32/+33
| | | | | | | | | 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.
* tracker-utilities: Drop unused nautilus_tracker_get_miner_fs_busnameCorey Berla2022-12-282-26/+0
|
* file-operations: Apply existing FAT filename rules to exfatCorey Berla2022-12-261-0/+1
| | | | | | | | | exfat invalid characters align with our existing FAT_FORBIDDEN_CHARACTERS, so we can simply add "exfat" to make_file_name_valid_for_dest_fs() See: https://learn.microsoft.com/en-us/windows/win32/fileio/exfat-specification#table-35-invalid-filename-characters Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/2059
* file-operations: Remove unnecessary filesystem checkCorey Berla2022-12-261-5/+3
| | | | | | | fat, vfat, and msdosfs are never returned by GIO. This code was added in f952bc29a3b5c1076fef916ffafd87eb8fff7a05 pre-GIO. See: https://gitlab.gnome.org/GNOME/glib/-/blob/main/gio/glocalfile.c#L669
* nautilus-window: do not override last_location for root promptGary Li2022-12-261-14/+13
| | | | | | | | | | | | | Currently, nautilus_location_entry_cancel uses the last_location GFile to reset the location entry path if the user cancels. However, the root prompt immediately overrides last_location by setting the location to "/", which results in the user always seeing "/" even if they cancel location bar entry then use CTRL-L to check current path. To fix this, use the same logic as the home prompt, which only sets the entry text. Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/2249
* general: Stop using gtk_widget_show and gtk_widget_hideCorey Berla2022-12-2524-134/+90
| | | | | | | Replace with gtk_widget_set_visible() or gtk_window_present() In some cases we use gtk_widget_show() unnecessarily because widgets are visible by default
* file-operation: Apply FAT filename rules to samba sharesCorey Berla2022-12-241-1/+7
| | | | | | | | | | | We check if a filesystem is FAT, NTFS, etc in order to apply windows based filename rules, but if we are copying to a smb share, those filesystem checks aren't performed. The simple solution is to check the "cifs" filetype also, but this fails because the filesystem_type is never checked since the smb share doesn't return the error INVALID_FILENAME. Instead it returns INVALID_ARGUMENT (and NOT_DIRECTORY for '\'). Since we are not handling those errors anyways, to be safe let's handle it the same way we do INVALID_FILENAME
* autorun-software: Add error message for not executableAntónio Fernandes2022-12-241-7/+12
| | | | | | | | | We currently state the program was not found, when in fact it was, but could not be accepted as it was not executable. So, provide an tailored error for that case. Resolves https://gitlab.gnome.org/GNOME/nautilus/-/issues/2675
* progress-persistence-handler: Ensure we release applicationGary Li2022-12-241-0/+4
| | | | | | | | | | | We wait for ::finished to release the application hold. NautilusProgressInfo emits this signal in a idle callback. But if it gets destroyed in the meantime, the idle source is removed. As a result, the ::finish signal never gets emitted and we keep holding the application forever. So, keep it alive while we wait for the ::finished signal.
* progress-info-manager: Don't leak finished & cancelled infosGary Li2022-12-241-0/+1
| | | | | | | | | | | NautilusProgressInfoManager aquires a reference for every progress info and keeps these references in a list. Upon destruction, it releases the reference while unreffing each progress info. However, when it removes finished and cancelled infos from the list, it doesn't release the reference, effectively leaking it. This bug is a old as the manager: a0f89473830575ae39a568608bc58f3f92c6f4a4
* progress-indicator: Disconnect signals from cancelled operationsGary Li2022-12-241-6/+6
| | | | | | | | | | | If the user cancels an operation and closes the window, Files crashes. This happens because disconnect_progress_infos() does not disconnect all signals taking *self as data, allowing use-after-free bugs. Use g_signal_connect_object() to fix this implicitly. Fixes https://gitlab.gnome.org/GNOME/nautilus/-/issues/1965
* file: Check minimum thumbnail size independently from scaleAntónio Fernandes2022-12-241-17/+1
| | | | | | | | | | | | We've been allowing thumbnails at smaller sizes if the screen density is larger. This goes back to 7059cc66ca3bc338e49a6ac4cb37c3484ba3b19d This leads to inconsistent results depending on the screen density. Also, the human eye is the limiting factor here. So, replace the helper function with a simple size check. Fixes https://gitlab.gnome.org/GNOME/nautilus/-/issues/1804
* grid-view: Reintroduce 64px icon sizeAntónio Fernandes2022-12-242-0/+8
| | | | | | | | | | | As we have introced a new extra large icon size at 256px, we have cut the 64px icon size, in an effort to keep the number of sizes at 4. To my surprise, some people care very strongly about the 64px size: https://discourse.gnome.org/t/icon-view-sizes-in-nautilus-43/11240 Although I'm yet to understand why it matters, I hope to make the upgrade to 43 smoother by adding back this size.
* grid-view: Show more captions per zoom levelAntónio Fernandes2022-12-241-1/+1
| | | | | | | | | | | In the old grid view, the maximum number of captions per zoom level followed the sequence 1, 2, 3, 3. In the new grid view, it follows the sequence 0, 1, 2, 3. This was an accidental regression, which I'm fixing now. Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/2530
* nautilus-toolbar: add mnemonics for New Window/TabPeter Eisenmann2022-12-241-2/+2
| | | | Fixes #2465
* file-operations: Remove unused booleanAntónio Fernandes2022-12-231-8/+0
| | | | It's always FALSE and the previous commit removed its single use.
* file-operations: Always unlock worker thread on GtkDialog::resposeAntónio Fernandes2022-12-231-5/+0
| | | | | | | | | | | | | | | | | | | The worker thread is blocked while waiting for user response on the main thread, through a GtkDialog. It gets unblocked upon response. Except... we have an early return on our ::response hanlder, which causes the worker thread never to be unblocked. This comes from 38a04943f9029ed4e8c7481b05502454a82a2811 The apparent intention was to presenve the behaviour from when we were would calling gtk_dialog_run() in a loop. Maybe it worked under GTK3, but it definitely doesn't under GTK4. Fortunately, this should be dead code, because data->ignore_close_box is always FALSE. Yet, under irregular situations, it may be reached, as the following report suggests. So, it's best to remove this code which is both wrong and unused. Closes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/2604
* search-popover: Search other types descriptionAntónio Fernandes2022-12-231-1/+14
| | | | | | | | | | | | | Currently we search only the mime-type string, because it was more convenient for programming. But it's obviously inconvenient for users, because the string shown in the list (i.e. the localized description) doesn't match the strings being searched. This becomes worse when the language is not English. Use a more advanced expression to search both the mime type string as well as its localized description. This fixes https://gitlab.gnome.org/GNOME/nautilus/-/issues/2659
* files-view: Only set discrete scrolling when ctrl is heldCorey Berla2022-12-231-2/+25
| | | | | | | | | | | | The scroll controller on the scrolled window in files view is set to discrete in order to accomodate for when CTRL+scroll (zoom) is performed. This however, causes problems with the scrolls that are propogated and have delta's <1 (especially when they are much much less 1). So instead let's set the discrete flag in scroll-begin only when CTRL is held and remove it in scroll-end. Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/2511
* list-base: Don't ring error bell from sushiAntónio Fernandes2022-12-231-4/+0
| | | | | | There is no bell ringing in the same situation with using arrow keys directly, so there is not reason to have them when bridging the keys from sushi.
View Lorry Controller Status