Signed-off-by: gaobo <gaobo@kylinsec.com.cn>
Small images were loading thumbnails at their native pixel dimensions after being selected, instead of being scaled to the icon view's display size. This means that when clicking or selecting those images, they visually shrunk. Fixes #1871
This caused unselected icons to unconditionally rebuild their surface on every frame draw.
* search: Respect hidden files setting when searching When starting a search, check the current window's hidden files mode and apply the same setting to search results. This ensures search results match the visibility of files in the current directory view. * search: Add support for globs Add globbing when searching for files. Caja will autodetect if the query contains a glob and change its search to use that instead of substrings. Example: - "*.txt" finds all text files - "photo-?.jpg" finds numbered photo files - "data[0-9]*.csv" finds numbered data files * search: Add location tooltips for search results Display file location in tooltips when hovering over search results in both icon and list views. This can help users tell where files are located since search happens across subdirectories.
Display the git branch along with directory name in icon view; when the directory is a git repository. Obviously further work will be required to enable/disable as a displayed option, and potentially some level of customisation. This would require open discussion of possibilities. Solutions for co-existence with other displayable parameters also to be community determined. Consideration and feedback appreciated. * Add UI support to enable/disable option Added user interface support for option to enable and disable the display of the git branch name in icon view. * Add internationsation support for the new feature With translations for most of the currently supported languages. * Update caja.pot Build system regenerated .pot file with additional strings from new feature (already in previous commit), new strings already introduced to code-base, along with updated source file line numbers of existing strings. Required for the automated pull mechanism in Transifex - which should complete once merged with master branch.
The G_FILE_ATTRIBUTE_STANDARD_CONTENT_TYPE attribute doesn't have to be always set. See https://gitlab.gnome.org/GNOME/gvfs/-/merge_requests/68 for more details. In that case, Caja fallbacks to the "application/octet-stream" type, which causes issues when opening the files. Let's fallback to the "standard::fast-content-type" attribute instead to fix issues when opening such files. Imported from Nautilus commit: https://gitlab.gnome.org/GNOME/nautilus/-/commit/0e5978035b0fc87c91d7b93ed79c64d51b6d6825 Fixes #1840.
* Do not attempt to unref or destroy a child of a container *In GTK 3 at least, GtkContainers automatically destroy child widgets when destroyed
As done for copy/delete jobs, restart the operation timer also for move jobs. Thus preparations (e.g. `scan_sources`) later won't affect the later transfer rate calculation. caja-file-operations: stop timer when waiting When a copy/move operation is created while another operation is already active, the new operation is queued. As the (already running) operation timer of the new operation is not stopped during the waiting period, that period is (erroneously) included in the transfer rate calculation and leads to initially low/slowly increasing transfer rates be shown. Hence stop the operation timer when the (queued) operation is waiting. Fixes #1420 and #1623.
* caja-file-operations: fix estimate for queued copy Fixes the condition for showing an estimate of the remaining duration in case a copy operation is queued, correctly considering the current transfer rate. * caja-file-operations: fix division by 0 for delete Aligning to the copy operation case, this fixes the condition for showing an estimate of the remaining duration for delete operations, preventing a possible division by 0 due to a zero transfer rate.
For certain operations, the destination is checked. If an error occurs, the user is asked how to proceed using a dialogue. So far this dialogue was hard-coded to only consider the copy operation. This fix also considers the other affected operations and generalizes the continue button text.