Files issueshttps://gitlab.gnome.org/GNOME/nautilus/-/issues2024-03-11T21:55:07Zhttps://gitlab.gnome.org/GNOME/nautilus/-/issues/3362Drag and scroll at the same time2024-03-11T21:55:07ZEuri MonteroDrag and scroll at the same timeThe following suggestion improves productivity when you work a lot with nautilus. Nowadays when you're gonna drag a file to drop it on a different window, usually you need to go at the top or the bottom of the window to view the hidden f...The following suggestion improves productivity when you work a lot with nautilus. Nowadays when you're gonna drag a file to drop it on a different window, usually you need to go at the top or the bottom of the window to view the hidden folders to drop the file on them.
But... What if you got hundred or files? It takes a lot of time to up or down. Simply, just use the mouse's physical scroll to up or down the window's elements, oh no! you cannot, the scroll doesn't work until you drop the item dragged, you need to drop the item in the current window, and cut and paste the item or wait an eternity until the desired folder is shown.
This suggestion solves this problem. With a single file or folder it's an insignificant problem, but it takes a lot of time and it's very annoying when you work with bunches of files.
Thank you.https://gitlab.gnome.org/GNOME/nautilus/-/issues/3333Expose favorite folders to Overview search2024-02-26T03:37:45ZfortellerExpose favorite folders to Overview search# Affected Version
- Version: 45.2.1
- Distribution: Nobara 39
- Also affects development version: Don't know, it wouldn't start
### Use Cases
Hi. Thank you for your work! I mostly find Files to be a good file manager, but I miss bette...# Affected Version
- Version: 45.2.1
- Distribution: Nobara 39
- Also affects development version: Don't know, it wouldn't start
### Use Cases
Hi. Thank you for your work! I mostly find Files to be a good file manager, but I miss better integration with the rest of the OS. At least with favorite folders. When I add folders as favorites that's because I often have to go to those folders. Thankfully it's very easy to add and remove favorites, so I can always have my most used folders there.
When these are the folders I use the most, that also means it's the ones I want to open the fastest. But if I have multiple folders with the same name, the search in Overview never cares about my favorites and it gives me the same order of results every time, and I have to navigate down past the folders I never open to get to the one I open all the time. And if I have multiple folders starting with the same letters, the Overview search does not guess that I want one of the favorite folders when I start typing, so I still have to type as many letters to find it as I would have to if it was not favorited.
Let's say I take a lot of screenshots and I want to look over them often and dragndrop the ones I need into something. Searching for "screenshot" in Overview only gives me search results from Files that are individual screenshot files, from years ago. If I have my folder named Screenshots in my favorites I would expect that to show up first. Just and example, there are tons of work situations where getting to some specific folders fast is advantageous. I'm sure that's why the fav feature exists at all.
### Available Workarounds
There are extensions that can put a menu of folders in the top bar, I don't know if you can navigate them with keyboard only. Other than that it's just the way mentioned above, I think.
### Difficulties
The usefulness of the Overview search is highly diminished. Instead of going directly from search to the folder I work with all the time I have to first open Files then either tab very far down the sidebar or move my hand to the mouse and click on the favorite folder. One thing is that this takes more time. Worse is that it seems so unintuitive and broken.
### Suggested Enhancements
In addition to exposing fav folders in search it would also be nice if one could add specific folders (favs or not) to the Dash.
Thanks again for all you do, and for taking the time to listen!https://gitlab.gnome.org/GNOME/nautilus/-/issues/3330Rethink "Last Modified" Sort for Icon and List view2024-03-06T12:06:22ZMershlRethink "Last Modified" Sort for Icon and List view# Affected Version
- Version: Nautilus 40+ (potentially previous versions)
- Also affects development version: Yes
### Use Cases
The `Last Modified` sort option in Nautilus sorts files solely by their `Modified` date.
A typical workflo...# Affected Version
- Version: Nautilus 40+ (potentially previous versions)
- Also affects development version: Yes
### Use Cases
The `Last Modified` sort option in Nautilus sorts files solely by their `Modified` date.
A typical workflow for downloading an archive can show the following situation:
1) The `Downloads` directory of a user is set to be sorted by `Last Modified`
1) An archive is downloaded to `~/Downloads`
1) The archive is extracted, the files are sorted into the Icon/List view by their original `Modified` date and Nautilus scrolls to the extracted files
1) The user closes Nautilus or switches directories and comes back to the `Downloads` directory at a later time
1) The user remembers the recently extracted files but has a hard time locating the recently extracted files in the Icon/List view as they are potentially sorted deep into the directory.
### Available Workarounds
Staying with the example above:
Modifying or touching the files after extraction will update their `Modified` date and bring them closer to the "expected" position of the user. Though, the modification might have unintended sideeffects, like accidently adding content to the file by the user or the file relying on it's `Modified` date (for sync or upgrade purposes).
### Difficulties <!-- Why is the current experience unsatisfying? -->
Users might have an expectation of finding recent files on top of the list when sorting by `Last Modified`. Sorting extracted files by their original `Modified` date is often times misunderstood by the user ("Why is this picture I extracted *yesterday* way down the list?").
Users previously using other filemanagers (like Windows-Explorer or MacOS Finder) have the expectation of extracted files been sorted to the top, right after extraction. The implementation of these filemanagers is not open, but a combination of Creation Date and Modification Date is to be assumed from their behaviour.
### Suggested Enhancements <!-- Optional - the other sections are more important. -->
A possible solution could be to combine the `Created` and `Modified` date of a file or directory when sorting. Using the newer of the two dates would be closer to the expectation of the user.
An additional challenge is the availability of the `Created` attribute. Not all filesystems or filesystem versions support this attribute.
Proposals:
1) Rename `Last Modified` sorting option to `Last Changed` and use both `Modified` and `Created` (if available, else only use `Modified`) date.
1) Introduce a separate sorting option `Last Changed` which uses both `Modified` and `Created` (if available, else only use `Modified`) date.
1) Introduce a separate sorting option `Last Changed` which combines `Created` and `Modified` date and is only available if `Created` attributes are supported for the current directory's filesystem.
Shoutout to @antoniof for the possible wording of a new sorting option. Suggestions: `Last Modified or Created`, `Last Changed`, `Last Touched`https://gitlab.gnome.org/GNOME/nautilus/-/issues/3329Trash for non-home directories if the owner is a non-root user2024-02-22T07:44:25ZProneel PalTrash for non-home directories if the owner is a non-root user# Affected Version
- Version: 45
- Distribution: Fedora 39
- Also affects development version: Yes
### Use Cases and Difficulties
* For example, there is a user named `example` and is owner of `/storage` directory, which is mounted un...# Affected Version
- Version: 45
- Distribution: Fedora 39
- Also affects development version: Yes
### Use Cases and Difficulties
* For example, there is a user named `example` and is owner of `/storage` directory, which is mounted under root.
* He can only delete a file/folder inside `/storage` permanently but not move to trash.
* Whereas if Nautilus opened as root, it shows "Move to trash" option and moves file/folder to root trash
* In KDE Dolphin, `example` user can move any file/folder under `/storage` to trash.
### Suggested Enhancements
"Move to trash" option for non-home directories whose owner is a non-root user.https://gitlab.gnome.org/GNOME/nautilus/-/issues/3328View Name can be Arbitrarily Long in a View Status Page Description2024-02-21T14:50:42ZKhalid Abu ShawaribView Name can be Arbitrarily Long in a View Status Page DescriptionThe following discussion from !1447 should be addressed:
- [ ] @antoniof started a [discussion](https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/1447#note_2011135): (+7 comments)
> Folder names can be arbitrarily long. We shou...The following discussion from !1447 should be addressed:
- [ ] @antoniof started a [discussion](https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/1447#note_2011135): (+7 comments)
> Folder names can be arbitrarily long. We should consider whether and how to deal with that.
>
> In some cases we have been truncating names longer than a certain number of characters. Should we do the same here?https://gitlab.gnome.org/GNOME/nautilus/-/issues/3326Awkward empty trash dialog2024-03-13T11:43:32ZAllan DayAwkward empty trash dialogWe are still showing this dialog when someone unmounts a removable drive:
![image](/uploads/9336bd3ccac4602fea428d153c37a584/image.png)
There's a discussion about the high level design of this dialog in #2597, but that hasn't settled o...We are still showing this dialog when someone unmounts a removable drive:
![image](/uploads/9336bd3ccac4602fea428d153c37a584/image.png)
There's a discussion about the high level design of this dialog in #2597, but that hasn't settled on a solution. Meanwhile, the dialog itself is rather unusual and awkward looking:
* The phrasing and capitalization of the heading is non-standard
* The vertically stacked buttons are unusual
* The button labels are rather verbose
* The button order is wrong - cancel should come first
* Having both "Cancel" and "Do not Empty Wastebasket" is confusing - how are they different?
While this dialog continues to exist, it would be good to polish off these rough edges. A design like the following could work:
![image](/uploads/e010fa5ad7208cb7eaaa46cfc07605a1/image.png)https://gitlab.gnome.org/GNOME/nautilus/-/issues/3314Cancelling of Future Directory Callbacks When Cancelling Current Ones.2024-02-12T10:52:54ZPeter EisenmannCancelling of Future Directory Callbacks When Cancelling Current Ones.The following discussion from !1375 should be addressed:
- [ ] @p3732 started a [discussion](https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/1375#note_1981239): (+4 comments)
> `remove_callback_link` returns the updated l...The following discussion from !1375 should be addressed:
- [ ] @p3732 started a [discussion](https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/1375#note_1981239): (+4 comments)
> `remove_callback_link` returns the updated list, wouldn't it be enough to lookup it once and then reuse the result of that?https://gitlab.gnome.org/GNOME/nautilus/-/issues/3308Redesign search information2024-03-09T16:05:53ZAntónio Fernandesantoniof@gnome.orgRedesign search information# Current Design:
Ugly, intrusive pseudo-banner:
![image](/uploads/5c7136a6caef9888e58641950161875a/image.png)
* If recursive search is disabled for local folder, it says: `"Searching locations only"`
* If recursive search is disabled...# Current Design:
Ugly, intrusive pseudo-banner:
![image](/uploads/5c7136a6caef9888e58641950161875a/image.png)
* If recursive search is disabled for local folder, it says: `"Searching locations only"`
* If recursive search is disabled for remote folder, it says: `"Remote location — only searching the current folder"`
* As recursive search is always disabled in Other Locations, it says: `"Searching locations only"`
* As recursive search is always disabled in Network, it says: `"Searching network locations only"`
# New design:
https://gitlab.gnome.org/Teams/Design/app-mockups/-/blob/master/files/files-search-46.png?ref_type=headshttps://gitlab.gnome.org/GNOME/nautilus/-/issues/3306Global Search ("Search Everywhere") keyboard shortcut clears search results i...2024-02-16T16:07:43ZJeff FortinGlobal Search ("Search Everywhere") keyboard shortcut clears search results instead of refocusing & selecting the search queryThis is essentially the same request as #2819 that was fixed by @abu_shawarib, but to bring that safety & consistency to the Global Search as well: if I search for something globally, then defocus the searchbar (ex: by keyboard-navigatin...This is essentially the same request as #2819 that was fixed by @abu_shawarib, but to bring that safety & consistency to the Global Search as well: if I search for something globally, then defocus the searchbar (ex: by keyboard-navigating to some other widget in the UI, or selecting some of the search results), pressing the Search Everywhere keyboard shortcut(s) again should refocus the searchbar and preselect its contents (see issue 2819 for the detailed logic / reasons behind this).https://gitlab.gnome.org/GNOME/nautilus/-/issues/3292No way to know the location of a file/folder when searching in grid view2024-02-05T20:12:36ZNokseNo way to know the location of a file/folder when searching in grid view<!--
It's useful to know if the latest development version has the same shortcoming.
It can be installed alongside the regular version with these instructions:
1. Make sure that Flatpak is installed (see https://flatpak.org/setup )
2. ...<!--
It's useful to know if the latest development version has the same shortcoming.
It can be installed alongside the regular version with these instructions:
1. Make sure that Flatpak is installed (see https://flatpak.org/setup )
2. Copy and run the following command in the Terminal or Console app:
flatpak install --from https://nightly.gnome.org/repo/appstream/org.gnome.NautilusDevel.flatpakref
3. Launch the development version (normal Files logo with yellow and black stripes), e.g. with:
flatpak run org.gnome.NautilusDevel
-->
# Affected Version
- Version: 45.2.1
- Distribution: Fedora 39
- Also affects development version: Yes
### Use Cases
<!--
Describe concrete situations, from daily usage, in which this app isn't helpful enough.
Focus on what you want to do, not how it should be done, but do mention possible constraints.
-->
When searching for something in grid view is hard to know the file/folder location.
Especially if there are multiple files/folders with the same name in different places.
### Available Workarounds <!-- Can the goal be achieved with the current app version? -->
When searching in grid view you have to open each file/folder property window to know the location.
### Difficulties <!-- Why is the current experience unsatisfying? -->
Tedious to know each file location when searching in grid view. You have to switch to list view when searching if you want to know the path or open the properties.
### Suggested Enhancements <!-- Optional - the other sections are more important. -->
There should be a tool-tip for each file/folder with the path (only when searching)https://gitlab.gnome.org/GNOME/nautilus/-/issues/3289Use shortened message strings variants for operations progress indications in...2024-03-13T14:54:39ZJeff FortinUse shortened message strings variants for operations progress indications in the new sidebarWith the upcoming 46 release, instead of being only stuffed into a pie, operation summaries will be shown at the bottom of the sidebar. However, those strings currently get truncated 100% of the time, because they are the same detailed s...With the upcoming 46 release, instead of being only stuffed into a pie, operation summaries will be shown at the bottom of the sidebar. However, those strings currently get truncated 100% of the time, because they are the same detailed strings as the ones found in the detailed progress popover widget:
![Screenshot_from_2024-01-31_10-41-01](/uploads/4929c01f561572b4de67661cbf3d6136/Screenshot_from_2024-01-31_10-41-01.png)
We would need to use "short abstract" variants of those strings here, specific to the sidebar, to avoid situations such as "into …", given the sidebar's width constraints.
This would at least reduces the likelyhood of nonsensical incomplete sentences in that particular context (as `to %s`, `into %s`, etc. will always be incomplete there).
So it could become something like:
* `Compressing %d items…`
* `Moving %d items…`
* `Copying %d items…`
I'm not entirely sure if hardcoding the ellipsis (`…`) symbol into the string could be "too much" and risk triggering ellipsization of the ellipsis in some languages, but it could help indicate that there is "more info" to be seen when clicking those progress indicators…GNOME 47Corey BerlaCorey Berlahttps://gitlab.gnome.org/GNOME/nautilus/-/issues/3280Explore NautilusDirectory Design2024-01-29T16:55:04ZCorey BerlaExplore NautilusDirectory DesignShould NautilusDirectory guarantee that callbacks are cancelled on dispose?
See https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/1406#note_1989574Should NautilusDirectory guarantee that callbacks are cancelled on dispose?
See https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/1406#note_1989574https://gitlab.gnome.org/GNOME/nautilus/-/issues/3278Rework the UI for setting custom icons for folders2024-01-26T22:15:06ZSam Hewittsnwh@gnome.orgRework the UI for setting custom icons for folders![image](/uploads/e9837dedb34bedbc8fe2325f09f8d199/image.png)
The UI for the feature to set a custom icon for folders in the properties dialog could be reworked a bit to address a few things:
- the term could be changed from "Icon" to ...![image](/uploads/e9837dedb34bedbc8fe2325f09f8d199/image.png)
The UI for the feature to set a custom icon for folders in the properties dialog could be reworked a bit to address a few things:
- the term could be changed from "Icon" to "Image" to more accurately reflect that you can set any image
- the custom image is only a local change so that needs to be reflected in the UI
- we don't want people to invest a lot of time into setting custom images when the change is only local
- the pencil icon button is just a file chooser which is a bit incongruous so it needs a different pattern
~~This mockup shuffles the pieces of this feature around so that setting a custom image is an action from a menu in the dialog, a banner is always present if a custom image is set to inform users (with a "Remove" button to set it back to the default).~~
![image](/uploads/f8086c0c6ce82b0b4f34d95978e3aa8f/image.png)https://gitlab.gnome.org/GNOME/nautilus/-/issues/3226"Delete permanently" modal should not have "Delete" focused initially, at lea...2023-12-14T22:36:08ZGN"Delete permanently" modal should not have "Delete" focused initially, at least if triggered with Delete key (data loss risk)<!--
Please test if the issue has already been fixed by installing the latest testing version.
It can be installed alongside the regular version with these instructions:
1. Make sure that Flatpak is installed (see https://flatpak.org/se...<!--
Please test if the issue has already been fixed by installing the latest testing version.
It can be installed alongside the regular version with these instructions:
1. Make sure that Flatpak is installed (see https://flatpak.org/setup )
2. Copy and run the following command in the Terminal or Console app:
flatpak install --from https://nightly.gnome.org/repo/appstream/org.gnome.NautilusDevel.flatpakref
3. Launch the development version (normal Files logo with yellow and black stripes), e.g. with:
flatpak run org.gnome.NautilusDevel
-->
# Affected Version
- Version: 45.1
- Distribution: N/a
- Happens with development Flatpak: Yes
### Use Cases
<!--
Describe concrete situations, from daily usage, in which this app isn't helpful enough.
Focus on what you want to do, not how it should be done, but do mention possible constraints.
-->
If browsing a location that doesn't support "move to trash" (e.g. an SFTP location, <Delete> shows a "delete permanently" modal, with "Delete" focused.
This presents a significant accidental deletion risk, because the Delete key and Enter are next to each other on full-size keyboards. This means it is easy to fat-finger when trying to hit Enter, and hit Delete instead, possibly immediately followed by Enter, causing deletion when navigation was intended.
### Available Workarounds <!-- Can the goal be achieved with the current app version? -->
Disabling the keybinding entirely??
### Difficulties <!-- Why is the current experience unsatisfying? -->
Accidentally deleting whatever item is focused, instead of opening it.
### Suggested Enhancements <!-- Optional - the other sections are more important. -->
Any of the following would fix this issue:
* Don't focus Delete on the modal.
* Only focus Delete on the modal if shown via the mouse or via Shift+Delete.
* Don't attach Delete to "delete permanently" at all in cases where "move to trash" is unavailable (possibly showing a non-modal message suggesting "shift-delete").https://gitlab.gnome.org/GNOME/nautilus/-/issues/3217Clicking current location in overlaid sidebar doesn't close it2024-02-08T05:40:30ZAntónio Fernandesantoniof@gnome.orgClicking current location in overlaid sidebar doesn't close itThe following discussion from !1296 should be addressed:
- [ ] @PhilippSauberz started a [discussion](https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/1296#note_1939074): (+1 comment)
> I just tried this implementation and...The following discussion from !1296 should be addressed:
- [ ] @PhilippSauberz started a [discussion](https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/1296#note_1939074): (+1 comment)
> I just tried this implementation and it works well in general. The only inconsistency I found is that it doesn't close the sidebar when clicking on the current location. It definitely should also close the sidebar in that case because the user will get used to be able to close the sidebar by clicking on the locations. And going back to the current location is not an uncommon edge case. For example the user could have opened the sidebar to access the main menu button and not to navigate to a different location. Still the user would intuitively expect to be able to go back to the "Downloads" folder for example by clicking on it.https://gitlab.gnome.org/GNOME/nautilus/-/issues/3212Show operations progress indication in narrow view (without sidebar)2024-02-08T00:06:11ZNils ThieleShow operations progress indication in narrow view (without sidebar)# Affected Version
- Version: 45.1
- Distribution: Fedora 39
- Happens with development Flatpak: Yes (46.alpha.0-1c5bd3614)
### Use Cases
Since v45 the file transfer progress indicator button moved into the sidebar (top left).
When you ...# Affected Version
- Version: 45.1
- Distribution: Fedora 39
- Happens with development Flatpak: Yes (46.alpha.0-1c5bd3614)
### Use Cases
Since v45 the file transfer progress indicator button moved into the sidebar (top left).
When you do any file transfers with the sidebar hidden you won't get any visible progress indicator until the transfer is finished (toast notification).
### Available Workarounds
None
### Difficulties
I think current file transfers progress is an important information that should be presented to the user in any case.
### Suggested Enhancements
Maybe the widget could be mirrored to the bottom toolbar that gets displayed when the narrow width breakpoint is activated.https://gitlab.gnome.org/GNOME/nautilus/-/issues/3189Starred items should show at the top of global/recursive search results2024-02-08T05:44:21ZJeff FortinStarred items should show at the top of global/recursive search resultsSomething that could make the Star System more meaningful to some users (like me) would be to have ⭐ items always pinned to the top of search results matches (when they are part of the matches).
Personally, I'd expect this to work for g...Something that could make the Star System more meaningful to some users (like me) would be to have ⭐ items always pinned to the top of search results matches (when they are part of the matches).
Personally, I'd expect this to work for global and recursive searches (i.e. not just when I'm in the home directory, but any other complex directory that has a bunch of subdirectories). It would alleviate just a tiny bit the pain I feel from not having "Sort folders first" respected for search since version 45.
---
To figure out the proper place to patch this in the search-related code, Antonio may have some special guidance to unlock The 5tory of the 5ecret 5tar 5ystem.https://gitlab.gnome.org/GNOME/nautilus/-/issues/3139Suggestions for improved usability of the batch rename dialog2023-10-19T21:27:14ZMitchel HumpherysSuggestions for improved usability of the batch rename dialog# Affected version
- Other: Arch Linux, Files 45.0
# Steps to reproduce
1. Select multiple files
2. Click "Rename"
3. Be confused
---
Batch renaming is a killer feature, but the template placeholders are currently hard to discover and...# Affected version
- Other: Arch Linux, Files 45.0
# Steps to reproduce
1. Select multiple files
2. Click "Rename"
3. Be confused
---
Batch renaming is a killer feature, but the template placeholders are currently hard to discover and not very intuitive.
The first time I used it I was at a total loss as to what template variables were available to me. I couldn't find documentation online (and my built-in help currently isn't working lol, looks like [this issue](https://bugs.launchpad.net/ubuntu/+source/yelp/+bug/2037633)). Ultimately I [asked for help on r/gnome](https://www.reddit.com/r/gnome/comments/17au2ce/what_placeholders_can_i_use_in_the_bulk_rename/) and it looks like I'm not the only one confused by the rename dialog.
I was educated on the "Add" button, and it's working great now, but my confusion and the confusion of other users seems like a pretty good signal that discoverability could be improved. I didn't even try the "Add" button, I think that I was thinking it would add more files to the list of files to be renamed. In any case, I definitely didn't think it would insert template placeholders.
The fix could be as simple as renaming the "Add" button to something like "Insert placeholder" (though that's a bit wordy?).
### Even Less Clicking
To go a step further (and this might need to be a separate issue), I noticed that typing `[1, 2, 3]` (or any other placeholder) into the input field doesn't enable the placeholder substitution, you actually *have* to go through the "Add" button. For me this is not ideal when I just want to quickly slap a numbered index onto some files I'm renaming (which I assume is a super common use case). I just want to type `new-name-[i].png` (/ `new-name-[ii].png` / `new-name-[iii].png`). The ability to control the order in which the files are renamed is nice, but perhaps that could be triggered by the presence of an enumerator template placeholder in the input field, rather than being triggered off of the "Add" drop-down.
<!-- Ignore the text under this line. -->https://gitlab.gnome.org/GNOME/nautilus/-/issues/3135Icons that are used in emblem_box are non-symbolic2023-10-18T17:23:18ZSam Hewittsnwh@gnome.orgIcons that are used in emblem_box are non-symbolicI'm not sure of all cases for icons that show up in the emblem_box outside of the standard emblem icons aside from mounted drive, but using non-symbolic icons here doesn't make much sense anymore, especially since it stays at 16x16 regar...I'm not sure of all cases for icons that show up in the emblem_box outside of the standard emblem icons aside from mounted drive, but using non-symbolic icons here doesn't make much sense anymore, especially since it stays at 16x16 regardless of zoom level, so might be worthwhile moving to using symbolics.
![image](/uploads/c8d1977e04f80f9e703a698c984f56a9/image.png) ![image](/uploads/0922331a978dfcf00f1d7bc07119defe/image.png)
cc-ing @jimmac as this would likely lead to deprecating the fullcolor emblem icons in a-i-thttps://gitlab.gnome.org/GNOME/nautilus/-/issues/3134GtkUriLauncher problems when handling trash2024-03-16T00:51:48ZKhalid Abu ShawaribGtkUriLauncher problems when handling trashThe following discussion from !1241 should be addressed:
- [ ] @antoniof started a [discussion](https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/1241#note_1852669): (+6 comments)
> This has another side-effect: now nautilu...The following discussion from !1241 should be addressed:
- [ ] @antoniof started a [discussion](https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/1241#note_1852669): (+6 comments)
> This has another side-effect: now nautilus opens trashed files.
>
> Say there is a file in trash with this URI: `trash:///example.txt`. Before this patch, `gio open trash:///example.txt` would open it in the text editor. Now, it opens nautilus in Trash with that file selected.
>
> So, we should investigate alternatives. Maybe it's the portal that needs to be fixed?