summaryrefslogtreecommitdiff
path: root/src/nautilus-file.c
Commit message (Collapse)AuthorAgeFilesLines
* file: Re-use local time zone when generating date stringSebastian Keller2023-04-201-10/+17
| | | | | | | | | | Whenever g_time_zone_new_local() is called it has to check the file system for changes, because the system's time zone might have changed since the last call. This function was called multiple times for each file when generating the date string, which was causing some unnecessary overhead. This changes the code to re-use the local time zone from the first call.
* Use generic helpers for obtaining file attributesOndrej Holy2023-03-091-6/+16
| | | | | | | | | | | | | | | | | | | | It is not guaranteed that all `GFileInfo` attributes are always set when requested. They used to be silently set to `NULL`, `FALSE`, or `0` earlier when they were not provided by their implementations. However, some of the helper functions now print critical errors when the attributes are not set by their implementations even though they were requested. See the https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3261 merge request for more details. So Nautilus now prints tons of critical errors when started. The unset attributes can be detected over the `g_file_info_has_attribute` function. But Nautilus doesn't care in most cases about the reason why the attribute is `NULL`, `FALSE`, or `0`. There are also more generic helper functions that don't print these critical errors. Let's use them for the attributes that may not always be set to get rid of those critical errors. I suppose that the `name`, `display_name`, `size`, `icon`, and `file_type` attributes don't need this special handling, although it is not clearly stated anywhere... Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/2861
* file: Cache clock format settingCorey Berla2023-03-051-9/+20
| | | | | | | | We are already caching the preferences for thumbnailing. Since the clock format is queried for every single file when loading a list view, we should also cache the clock format setting. Rename the flag from use_24 to use_24_hour for more clarity.
* file: Don't emit files_changed in file_class_initCorey Berla2023-03-051-4/+16
| | | | | | | | | | | | | In nautilus_file_class_init, we are calling thumbnail_limit_changed_callback() and show_thumbnails_changed_callback() in order to cache the initial values for the static variables cached_thumbnail_limit and show_file_thumbs. This has the unintended side effect of also calling emit_change_signals_for_all_files_in_all_directories () which doesn't make sense at a point in time when there are no NautilusFile's and NautilusDirectory may not even be ready. Split out the updating of the setting from the emission of all files changed.
* general: Replace deprecated GTimeVal with GDateTimeCorey Berla2023-01-091-3/+4
|
* general: Use gobject ADD_PRIVATE macrosCorey Berla2023-01-091-4/+3
| | | | Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/1022
* file: Generate thumbnails when the preview icon is availableOndrej Holy2023-01-041-0/+14
| | | | | | | | | | | | | 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
* 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
* eel: remove eel-glib-extensions.hPeter Eisenmann2022-12-231-1/+0
| | | | | Replace the eel_boolean_bit typedef with a plain guint and remove all includes.
* file: Format size in bytes with thousand separatorsAntónio Fernandes2022-12-221-1/+1
| | | | | | The separator used, if any, depends on locale. As per user suggestion in https://discourse.gnome.org/t/size-of-file-in-bytes-in-nautilus/12757/14
* file: Remove unused got_custom_activation_uriBenjamin Otte2022-12-131-6/+4
| | | | The last user was NautilusLink, and that's been gone for a while.
* file: Slightly soften thumbnail cornersAntónio Fernandes2022-09-011-0/+8
| | | | | | | | | Sharp corners give an unpolished feel to thumbnail. We've been trying to give the illusion of round corners using shadows. But now that we already use GtkSnapshot, properly clipping round corners is too easy not to do it.
* file: Drop "spacial file manager" leftoversAntónio Fernandes2022-09-011-63/+1
| | | | | | | | These flags were relevant when each folder opened in its own window, such that the open folders would have a different icon. Also, we would ignore that icon in properties. Spacial nautilus has been gone for maybe 15 years now.
* properties: Use existing flag to get mount iconAntónio Fernandes2022-09-011-0/+11
| | | | | | | Instead of duplicating the work here. Also push "upstream" the root directory special case which was recently added in commit 5722c394567d36f214fe58fb4bef7334b5209bad.
* file: Scale down thumbnails using GtkSnapshotAntónio Fernandes2022-09-011-55/+14
| | | | | | | | We've also been scaling thumbnails down in advance using GdkPixbuf API, and keeping a cache of scaled thumbnails. But nowadays we can push that scaling job into the render nodes, taking advantage of GPU. This is also a lot simpler.
* ui-utilities: Add filmholes using GdkSnapshotAntónio Fernandes2022-09-011-12/+21
| | | | This can take advantage of GPU and prepares for next changes.
* xicon-info: Take a paintables instead of pixbufsAntónio Fernandes2022-09-011-18/+4
| | | | | | This is more generic and is going to allow HiDPI icons and GPU usage. GdkPixbuf can be easily converted into GdkTexture, which is a GdkPaintable.
* properties-window: Fix disproportionate iconsAntónio Fernandes2022-09-011-10/+2
| | | | | | | | | | | Thumbnails in Properties were sometimes larger than the requested size. This is because we didn't pass the FORCE_THUMBNAIL_SIZE flag. There were probably good reasons for this flag in the past, but there are none now. If we request a size, that should be the size we get. So, drop this flag entirely and default to forcing the size everywhere.
* file: Check if special dir is the home directoryCorey Berla2022-08-301-0/+6
| | | | | | | | xdg-user-dirs is intentionally configured to disable a special directory when it's set to $HOME. Let's check if the file is pointing to the home directory and return early. Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/2459
* file: Drop string concatenation to make gettext work properlyOndrej Holy2022-08-151-3/+5
| | | | | | | | | The commit 35647f2 fixed build on 32-bit architectures using the relevant format string, but gettext isn't able to extract the text now due to string concatenation. Let's use the format string outside of the `ngettext` function to fix the issue. Related: https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/940
* file: Fix build using the correct format stringJeremy Bicha2022-08-111-2/+2
| | | | | | | The `%lu` format string doesn't match `goffset` type on 32-bit architectures Let's use the `G_GOFFSET_FORMAT` format string instead. Closes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/2419
* file: Update unknown labelsAntónio Fernandes2022-08-051-2/+3
| | | | | | | "Unknown" is displayed in Properties without a description, so add " type" to allow the user to make sense of it. Also capitalize "unknown" fallback.
* file: Follow HIG in own usernameAntónio Fernandes2022-08-051-2/+2
| | | | | | "You" is preferrable to "Me" https://developer.gnome.org/hig/guidelines/writing-style.html#guidelines
* properties-window: Show bytes in tooltipAntónio Fernandes2022-08-051-1/+4
| | | | | | | G_FORMAT_SIZE_LONG_FORMAT is, well, long. And redundact. But, oh, well, in case someone really wants to know bytes, we keep it as a tooltip.
* properties-window: Show current permissions in main pageAntónio Fernandes2022-08-051-0/+30
| | | | | | | This is immediately useful information. Deemphasize the action aspect: most people have no need for setting custom permissions.
* properties-window: Move size values under nameAntónio Fernandes2022-08-051-1/+4
| | | | | | | | | Instead of list row. This also means the list box where they used to be becomes the locations list, and must be hiden when none of its rows are shown. As proposed in mockups from https://gitlab.gnome.org/GNOME/nautilus/-/issues/2370
* file: Add trailing slash to parent pathAntónio Fernandes2022-08-051-4/+14
| | | | | | | | This makes it easier to tell it is a folder path. In a special case, for recursive search, where we omit the common prefix, this is especially important because direct subfolders would be a single basename without any slash.
* file: Drop folder-drag-accept icon usageAntónio Fernandes2022-08-041-7/+1
| | | | | | | | | | | | | Problems: - Changing icon without animation is crude. - If the folder has a custom icon, it doesn't change, which is inconsistent - And archives, which can accept drops, don't change icon, which is inconsistent. We already have css styling for drop targets so, which suffices. As per design review in https://gitlab.gnome.org/GNOME/nautilus/-/issues/2347
* properties-window: directly printable user namePeter Eisenmann2022-07-281-4/+4
| | | | | | | | | | Use a dash with spaces to separate user names and display names, rather than line breaks and splitting and recombining the string. For now the user name is still extracted for each entry, with the adaption to GListModel this will only be done when needed. Part of #1326
* file: Remove unused DND functionsCorey Berla2022-07-071-107/+0
| | | | Their purpose is now handled by `nautilus_dnd_get_prefered_action()`.
* general: Reimplement emblems as a box of iconsAntónio Fernandes2022-07-021-7/+3
| | | | | | | | | | | | | | | | | We used to display emblems overlaid on icons. This had a few problems: * Emblemed icons were not cached. * If the icon was too small, some emblems could be omitted. * Emblems would partially obstruct the visibility of thumbnails. So, we are reintroducing them as a mere box of icons: * vertically next to the file icon/thumbnail in grid view; * horizontally next to the filename in list view. This avoids all the problems of the old implementation. Closes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/2017
* file: Remove remaining GEmblemedIcon supportAntónio Fernandes2022-07-021-61/+1
| | | | | Emblemed icons are not implemented in GTK 4 and we don't want to reimplement them here anyway, so let's drop this code.
* enums: Redefine icon size optionsAntónio Fernandes2022-06-211-2/+2
| | | | | | | | | | | | | | | | | | | | | | | The new grid view introduces a new 256px icon size option, optimized for thumbnails. This was made possible because, unlike the old canvas, we have more control over the padding and can keep it low. However, with it, we have 5 size options now, which a little too many; in particular, the 64px size doesn't differ significantly enough from the 48px nor the 96px option now (the old canvas view this difference was more marked because padding increased in proportion). Similarly, the 48px option in the new list view is not significantly different from 32px and 64px. In the past, 32px didn't show thumbnails because the frames didn't allow the thumbnails to use the whole 32px; this would mark a difference vs. 48px. With the removal of thumbnail frames, this distinction is also gone. The 128px option in grid view is also not significantly larger than 96px and yet significantly smaller than 256px. Drop the superfluous sizes, replace 128px size with 168px size for a geometric progression and rename the enum symbols.
* tag-manager: Stop getting full referencesAntónio Fernandes2022-05-301-3/+4
| | | | | | | | It's really annoying having to setup a local autocleanup variable in every function we want to use the NautilusTagManager API. Use a NautilusUndoManager-like API instead, with new() returning a reference and get() not.
* file: Fix remote filesystem checkCorey Berla2022-05-101-1/+1
| | | | | | | | | | | | | | | | | Files are flagged as remote in file->details->filesystem_remote through directory-async as folders are browsed. nautilus_file_get_filesystem_remote() incorrectly returns FALSE for child directories that have not been processed by directory-async on a remote filesystem. This causes the "Count Number of Files in Folders" options to not work correctly when set to "On This Computer Only". Rather than unnecessarily process all of the child folders, check whether filesystem_info_is_up_to_date==TRUE. If not, check whether the parent is remote instead. This issue was introduced in 99f55748ef69a68df86b9a039998ee576d59b898. Previously the prefix of the URI was checked to match a hardcoded list. Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/2035
* file: Document ::{get,set}_metadata_list()António Fernandes2022-03-271-0/+17
| | | | | As they have been touched in the last two commits, and to clarify they don't actually mean a GList but rather a GStrv.
* file: Set metadata list as arrayAntónio Fernandes2022-03-271-18/+4
| | | | | | Same rationale as previous commit, this time for the setter. This saves a lot of futile array-->list-->array conversions.
* file: Get metadata list as arrayAntónio Fernandes2022-03-271-16/+14
| | | | | | | | | | | | | | | Metadata lists are attributes of type G_FILE_ATTRIBUTE_TYPE_STRINGV. In other words, they are gchar** (arrays of strings). Our NautilusFile API exports them as GList instead, but most calls happen in NautilusListView, which consumes arrays of strings. So, the conversion from array to list and back to array is wasteful. Let's start with the getter, making it return a string array isntead. For emblem keywords, we actually need a GList (for sorting), so make the conversion there after the getter call. The setter part is due in the next commit.
* general: Switch to GTK4António Fernandes2022-01-091-6/+19
| | | | | | | | | | | | | | | | The new major version of the toolkit is a requirement to fix old issues and enable future enhancements. Update symbols and adapt logic to API changes. Update and simplify UI definitions. Update local copy of places sidebar and places view. Replace dependencies with their GTK4-compatible successors. Make a minimum changes required to build and run, with known regressions to be fixed in future commits. For a detailed breakup of the changes, see the 36 commits-deep log leading to d5763facb1e5045251171ed1273dca0859f3542f. This is the main part of https://gitlab.gnome.org/GNOME/nautilus/-/issues/276
* file: Disable more emblems-related codeAntónio Fernandes2022-01-051-1/+3
| | | | To avoid build warnings about unused code.
* eel: Drop gtk extensionsAntónio Fernandes2022-01-051-1/+0
| | | | No longer used.
* file: Drop useless parameter from get_icon_pixbuf()António Fernandes2021-12-311-13/+2
| | | | Callers always pass TRUE nowadays anyway.
* general: Stop using GEmblemedIconAntónio Fernandes2021-12-311-0/+5
| | | | | | GTK 4 is not going to draw them anyway. Assume a temporary regression, to be fixed after the switch to GTK 4.
* general: Rename 'canvas' to 'grid' in enumsAntónio Fernandes2021-12-291-3/+3
| | | | | | These symbols are actually meant for both old and new "grid" views, in opposition to the "list" view, so this is a more appropriate name, considering both share NAUTILUS_VIEW_GRID_ID.
* file: Always use film strip for video thumbnailsAntónio Fernandes2021-12-291-9/+2
| | | | There is no reason not to do it for the new icon view now.
* Revert "nautilus-file.c: Add transparent padding to thumbnails"António Fernandes2021-12-291-23/+1
| | | | | | | | | | | | | | This reverts commit 26d33d74f468a8ab10b4a1c3c8aa66b66205e112. It was a hack to fix an issue with the way GTK 3 renders GEmblemedIcon. But GTK4 has dropped support for rendering GEmblemedIcon[0], so we aren't going to have any need for this hack going forward. Also, the new icon view now draws shadows around thumbnails. But due to this hack, the shadow would always go around the invisible square. [0] https://gitlab.gnome.org/GNOME/nautilus/-/issues/2017
* general: Remove thumbnail frameAntónio Fernandes2021-12-261-4/+0
| | | | | | | | | | Shadows are present in design mockups, frame is not. In GTK 4 we are going to be able to draw shadows in the new views using CSS, which is going to be much better than transforming pixbufs. Furthermore, this removes another use of libgd, which we want to stop depending on as part of the GTK 3-to-4 migration.
* file: Add constant for minimum size to useAntónio Fernandes2021-12-261-1/+1
| | | | | | | | | | | | | | | | | | | Currently, list view doesn't use thumbnails for its first zoom levels: SMALL (16px) and STANDARD (32px). So, it does display thumbnails for LARGE (48px) and LARGER (64px). On the other hand, the icon view uses displays for all zoom levels, the smallest being 48px. In short: thumbnails are displayed for zoom levels that request an icon size of 48 logical pixels. So, the minumum size of thumbs is 48px. This is implemented by checking that the current icon size is equal to or lower than NAUTILUS_LIST_ICON_SIZE_STANDARD (32px). However, we are going to need to check this condition in other places, so it would be best to have a constant specifically for this purpose. For the sake of naming this constant reasonably, let's use the minumum size of 48px and update the condition checking accordingly.
* file: Pass parent window to unmount operationAntónio Fernandes2021-11-221-2/+10
| | | | | | | It's conveniently set as a property of GtkMountOperation, so there is no reason not to pass both forward. This is necessary for the preceding commit to actually work as intended.
* file: use specific file type for Sort by TypeRajat Jain2021-11-161-0/+5
| | | | | | | | | | Adds file comparison based on actual file type, rather than generic type category. For example .jpg and .png files will now be sorted into two different groups. Fixes https://gitlab.gnome.org/GNOME/nautilus/-/issues/1776 Signed-off-by: Rajat Jain <rajatjain.ix@gmail.com>
View Lorry Controller Status