thunar issueshttps://gitlab.xfce.org/xfce/thunar/-/issues2023-09-06T00:33:56Zhttps://gitlab.xfce.org/xfce/thunar/-/issues/944Dont check executable bit/trusted flag for .desktop files in $XDG_DATA_DIRS2023-09-06T00:33:56ZAlexander SchwinnDont check executable bit/trusted flag for .desktop files in $XDG_DATA_DIRSFrom https://gitlab.xfce.org/xfce/thunar/-/issues/50#note_60122 (FYI @MichaIng)
```
Generally I agree that desktop launcher from anywhere shouldn't be trusted by default, although a setting to do so would be nice, also to align with ot...From https://gitlab.xfce.org/xfce/thunar/-/issues/50#note_60122 (FYI @MichaIng)
```
Generally I agree that desktop launcher from anywhere shouldn't be trusted by default, although a setting to do so would be nice, also to align with other desktop environments.
However, there is one bug in the current Thunar behaviour:
* /usr/share/applications is a trusted location: Every user can launch .desktop files from there without warning, manually from file explorer or via panel applications menu.
* If however a symlink is created from \~/Desktop/some.desktop to /usr/share/applications/some.desktop, it shows the warning, and the user cannot mark it as executable since it doesn't have write permissions, of course.
* I suggest to also trust symlinks to desktop launchers in trusted locations, especially the default one in /usr/share/applications. Packages do never ship those launchers with executable bit, but it makes much sense (and AFAIK is common practice) to symlink those to individual user desktops, like Kodi, htop, Chromium etc. It would be great if this worked without the permanent warning, as I cannot see any security downside. Since by default only root has write access to /usr/share/applications and any file inside, it is the even more secure solution, compared to creating own executable desktop launchers right within the users home dir, which in theory can be overwritten with user privileges.
I hope this makes sense. Best regards, Micha
```
Reading to the topic: https://askubuntu.com/q/419610/237592
The following got already fixed:
~~In addition with current thunar/exo master, there seems to be a problem with opening the preferences dialog for `.desktop` files which are not writable. E.g. open ` thunar /usr/share/wayland-sessions` and try to set the executable flag for `weston.desktop`.~~
~~At the first try thunar segfaults on setting the flag.
At the second try thunar segfault already on opening the preferences.~~Xfce 4.18Alexander SchwinnAlexander Schwinnhttps://gitlab.xfce.org/xfce/thunar/-/issues/692Add support to garcon's PrefersNonDefaultGPU2023-05-10T06:25:49ZAndre MirandaAdd support to garcon's PrefersNonDefaultGPUIf a desktop file contains `PrefersNonDefaultGPU=true` thunar should launch it with the following env vars:
- `__NV_PRIME_RENDER_OFFLOAD=1`
- `__GLX_VENDOR_LIBRARY_NAME=nvidia`
- `__VK_LAYER_NV_optimus=NVIDIA_only`
For more details see...If a desktop file contains `PrefersNonDefaultGPU=true` thunar should launch it with the following env vars:
- `__NV_PRIME_RENDER_OFFLOAD=1`
- `__GLX_VENDOR_LIBRARY_NAME=nvidia`
- `__VK_LAYER_NV_optimus=NVIDIA_only`
For more details see:
- https://gitlab.xfce.org/xfce/xfdesktop/-/issues/81
- https://gitlab.xfce.org/xfce/garcon/-/issues/21
- https://gitlab.xfce.org/xfce/garcon/-/merge_requests/16
- https://gitlab.xfce.org/xfce/xfce4-appfinder/-/merge_requests/17Xfce 4.18Andre MirandaAndre Mirandahttps://gitlab.xfce.org/xfce/thunar/-/issues/342Improve 'default application' handling2023-04-02T19:39:32ZAlexander SchwinnImprove 'default application' handling**Problem**
If no default application is defined, the last used application will be used to open a file on activation.
E.g. for pictures this might be annoying when opened with some graphic editor from time to time.
The current best pr...**Problem**
If no default application is defined, the last used application will be used to open a file on activation.
E.g. for pictures this might be annoying when opened with some graphic editor from time to time.
The current best practice is, to select open with --> other application and check the "default application" box in order to define the default to use. However that is kinda hidden. For some users it is not clear that this step is required.
**Proposed Solution**
1. If there is no default application set for a specific mime type, and the "open with" menu is used, the default will be set to the selected application.
2. Like 1. but some dialog would ask if that application should be used as default.
3. An additional item in the "open with" menu: "set default application". That would open the same dialog than "open with other application", but with "use as default" pre-selected.
I would go for 1. and 3. ... and optionally add 2. later on if someone complains.
Critics / Suggestions ?
Edit: As well it would help to highlight the default application in the list in some way, so that it is more clear that this application will be used per default. To be first of the list of "preferred applications" imo is not sufficient. Maybe a separate tree-headline "Default Application" would be good.Xfce 4.18Alexander SchwinnAlexander Schwinnhttps://gitlab.xfce.org/xfce/thunar/-/issues/520when copying and pasting multiple files, only the last file is selected after...2023-03-08T13:29:52Zjazzticketswhen copying and pasting multiple files, only the last file is selected after the pasteTested with thunar 4.16.3:
If you select multiple files, hit ctrl+c, then paste those files into a different directory, only the last file will be selected. All pasted files should be selected to be consistent with older versions of thu...Tested with thunar 4.16.3:
If you select multiple files, hit ctrl+c, then paste those files into a different directory, only the last file will be selected. All pasted files should be selected to be consistent with older versions of thunar and pretty much every file manager. It's nice to be able to see what was pasted in case you need to revert.
I believe this stopped working in version 4.16. I checked Ubuntu 20.04's 1.8.14 version and the selection is kept intact.Xfce 4.18https://gitlab.xfce.org/xfce/thunar/-/issues/819[GSoC 22] [undo] Add 'undo' for file operations2023-03-04T21:58:08ZPratyaksh Gautam[GSoC 22] [undo] Add 'undo' for file operationsThis is an issue to keep track of general discussion on the addition of 'undo' for file operations (requested in #191).
It is a part of my proposal for GSoC 22.
# Implementation brief
The implementation relies on the addition of a new t...This is an issue to keep track of general discussion on the addition of 'undo' for file operations (requested in #191).
It is a part of my proposal for GSoC 22.
# Implementation brief
The implementation relies on the addition of a new type, `ThunarJobOperation` to keep track of the latest operation(s) performed and allow for undoing them by calculating the inverse operation and executing it. Later additions would introduce a `GList` of such operations, and performing an undo should undo the latest operation, move the HEAD (pointer to the current state) backwards in history after undoing that operation. This would allow for 'redo' as well to be easily implemented by simply moving the head forward in history and executing the operation at the HEAD.
# TODO
The following MRs for each partial feature have to be added:
- [x] Undo for the single latest copy operation (!266)
- [x] Undo for single latest operation out of each of the following: move, rename, trash, link, create
- [x] Move (!281)
- [x] Rename (!288)
- [x] Trash (!289)
- [x] File creation (https://gitlab.xfce.org/xfce/thunar/-/commit/928e59c4868623f49cc08e192cdaa8ab691231c9)
- [x] Link (https://gitlab.xfce.org/xfce/thunar/-/commit/ff927e816e52135969aa56104e5801c4836df2bb)
- [x] Undo **and** redo for the single latest operation (https://gitlab.xfce.org/xfce/thunar/-/commit/98bc16cc641da75af30ae11b121a57514a272f6f)
- [x] Multi level undo/redo (https://gitlab.xfce.org/xfce/thunar/-/commit/98bc16cc641da75af30ae11b121a57514a272f6f)
- [X] Limit `job_operation_list` to e.g. 5 elements, so it does not grow indefinitely (configurable via xfconf prop) (!299)
- [x] Introduce mutex to protect `job_operation_list` and undo/redo pointers, since the variables can be accessed from within multiple threads (!305)
- [x] Add toolbar icons for undo/redo (!298)
- [x] Open separate issues for things mentioned in https://gitlab.xfce.org/xfce/thunar/-/issues/819#note_51642
- [X] small popup informing the user what operation they just undid (#903)
- [~] Allow users to access and view the recorded operation history in some way.Xfce 4.18Alexander SchwinnAlexander Schwinnhttps://gitlab.xfce.org/xfce/thunar/-/issues/497In a wayland session, no menu icons are shown2023-02-23T09:47:17ZAlexander SchwinnIn a wayland session, no menu icons are shownTested via weston session.
Neither in the "old" context menu of the bookmark view, nor in the new menus.
Nemo shows the same defect, so probably rather related to the weston session.
(Did not get Caja, or PCManFM to start in the westo...Tested via weston session.
Neither in the "old" context menu of the bookmark view, nor in the new menus.
Nemo shows the same defect, so probably rather related to the weston session.
(Did not get Caja, or PCManFM to start in the weston session, these somwwhat are lauched for my X11 session instead .. and Nautilus has no menu-icons)Xfce 4.18https://gitlab.xfce.org/xfce/thunar/-/issues/156Hiding filename/extention for .desktop files with execute permission.2023-01-29T10:33:25ZBugzilla MigrationHiding filename/extention for .desktop files with execute permission.## Submitted by Mathias Svanbäck
Assigned to **Xfce Bug Triage**
**[Link to original bug (#13329)](https://bugzilla.xfce.org/show_bug.cgi?id=13329)**
## Description
Created attachment 6980
Screenshot of malicious .desktop file dis...## Submitted by Mathias Svanbäck
Assigned to **Xfce Bug Triage**
**[Link to original bug (#13329)](https://bugzilla.xfce.org/show_bug.cgi?id=13329)**
## Description
Created attachment 6980
Screenshot of malicious .desktop file displayed in Thunar
Hiding the filename/extention may be used to trick users to execute arbitrary code.
How to reproduce:
1. Create a file called malware.desktop
2. Add the following content to it:
[Desktop Entry]
Name=CV.pdf
Exec=sh -c 'touch ./MALWARE_WAS_HERE'
Terminal=false
Icon=x-office-document
Type=Application
Categories=Office
3. Make it executable
Thunar displays the file like that: (see attachment)
Once the user opens the file the Exec entry is executed without any confirmation. By hiding the filename and therefore also the filename extension users can easily be tricked to execute arbitrary code when some ships files like that in an archive which preserves execute permissions.
How to fix it:
Maybe by don't hiding the filename for .desktop files at all.
/u/wander_homer brought it up
https://www.reddit.com/r/linux/comments/5r6va0/how_to_easily_trick_file_manager_users_to_execute/
For reference, this bug also applies to other file managers:
https://github.com/lxde/pcmanfm-qt/issues/449
https://github.com/mate-desktop/caja/issues/727
https://github.com/linuxmint/nemo/issues/1404
**Attachment 6980**, "Screenshot of malicious .desktop file displayed in Thunar":
![Screenshot_2017-02-02_19-14-19](/uploads/8488078496a68254907afec82cf285c3/Screenshot_2017-02-02_19-14-19.png)
Version: 1.6.10Xfce 4.18https://gitlab.xfce.org/xfce/thunar/-/issues/755Plugin menu do not show when run thunar --daemon2023-01-12T16:09:52ZFeng ShuPlugin menu do not show when run thunar --daemonI can not compile thunar master at the moment, so I backport below commit to xfce-4.16 branch to test,
maybe this issue does not exist in master.
```
8a3b98da Look for thunar plugins at $THUNARX_DIRS (Issue #748)
```
1. cd /path/to/thu...I can not compile thunar master at the moment, so I backport below commit to xfce-4.16 branch to test,
maybe this issue does not exist in master.
```
8a3b98da Look for thunar plugins at $THUNARX_DIRS (Issue #748)
```
1. cd /path/to/thunar
2. RUN: THUNARX_DIRS=/usr/lib/x86_64-linux-gnu/thunarx-3:/usr/lib/x86_64-linux-gnu/thunarx-3 ./thunar/thunar --quit
3. RUN: THUNARX_DIRS=/usr/lib/x86_64-linux-gnu/thunarx-3:/usr/lib/x86_64-linux-gnu/thunarx-3 ./thunar/thunar --daemon
Open another xfce terminal:
1. THUNARX_DIRS=/usr/lib/x86_64-linux-gnu/thunarx-3:/usr/lib/x86_64-linux-gnu/thunarx-3 ./thunar/thunar
![图片](/uploads/51336252b8eedb368a9014175d3aed0c/图片.png)
2. Close all thunar windows.
3 Run again: THUNARX_DIRS=/usr/lib/x86_64-linux-gnu/thunarx-3:/usr/lib/x86_64-linux-gnu/thunarx-3 ./thunar/thunar
![图片](/uploads/467b82515f25ecfd665386118dbc7383/图片.png)Xfce 4.18https://gitlab.xfce.org/xfce/thunar/-/issues/959Double-clicking on a .desktop file opens it in Mousepad instead of running it2022-12-10T21:03:25ZGaël BonithonDouble-clicking on a .desktop file opens it in Mousepad instead of running itI don't know if this is the desired behavior now (it seems to me that there have been security related changes in this regard), but in any case the behavior has changed between Thunar 4.16.11 and 4.17.12, and I find that this could appea...I don't know if this is the desired behavior now (it seems to me that there have been security related changes in this regard), but in any case the behavior has changed between Thunar 4.16.11 and 4.17.12, and I find that this could appear as a regression.
Steps to reproduce:
* [Download Tor Browser](https://dist.torproject.org/torbrowser/12.0/tor-browser-linux64-12.0_ALL.tar.xz).
* Extract the archive.
* Double click on the `.desktop` file in the extracted directory.
Thunar 4.16.11: Tor Browser starts.
Thunar 4.17.12: The file opens in Mousepad or other default text editor.Xfce 4.18https://gitlab.xfce.org/xfce/thunar/-/issues/174Easy to hide the menubar, tricky to get it back if the shortcut key is not known2022-11-14T09:17:43ZBugzilla MigrationEasy to hide the menubar, tricky to get it back if the shortcut key is not known## Submitted by Alexander Schwinn `@alexxcons`
Assigned to **Xfce Bug Triage**
**[Link to original bug (#13868)](https://bugzilla.xfce.org/show_bug.cgi?id=13868)**
## Description
Proposal 1:
- default "show menu" on each start of ...## Submitted by Alexander Schwinn `@alexxcons`
Assigned to **Xfce Bug Triage**
**[Link to original bug (#13868)](https://bugzilla.xfce.org/show_bug.cgi?id=13868)**
## Description
Proposal 1:
- default "show menu" on each start of thunar
- discard the menubar by the menu-item only changes visibility for current thunar-session
- default configurable via xfconf "menubar-visible"
- remove "last-menubar-visible" from xfconf
Proposal 2:
- Show some icon on the toolbar (only if menubar is hidden ) to get the menubar backXfce 4.18https://gitlab.xfce.org/xfce/thunar/-/issues/848Update Thunar software components for PCRE2 usage2022-11-04T15:00:28ZMarkus ElfringUpdate Thunar software components for PCRE2 usageI noticed that the dependencies for a Linux package of [this software](https://gitlab.xfce.org/xfce/thunar/-/blob/072bffbd3d5c4d6731a98943467b5cea59810fcf/acinclude.m4#L41 "Update candidate") contain the information “Requires: libpcre.so...I noticed that the dependencies for a Linux package of [this software](https://gitlab.xfce.org/xfce/thunar/-/blob/072bffbd3d5c4d6731a98943467b5cea59810fcf/acinclude.m4#L41 "Update candidate") contain the information “Requires: libpcre.so.1()(64bit)”.
:crystal_ball: How will the chances evolve to [support the API “PCRE2”](https://github.com/PCRE2Project/pcre2
"Support for Perl-compatible regular expressions") (with library versions ≧ 10.40)?Xfce 4.18https://gitlab.xfce.org/xfce/thunar/-/issues/123How about a sort by delete date in the Trash?2022-10-31T20:23:36ZBugzilla MigrationHow about a sort by delete date in the Trash?## Submitted by majest
Assigned to **Xfce Bug Triage**
**[Link to original bug (#12345)](https://bugzilla.xfce.org/show_bug.cgi?id=12345)**
## Description
In the Trash folder, you can sort by everything except delete date. Can you...## Submitted by majest
Assigned to **Xfce Bug Triage**
**[Link to original bug (#12345)](https://bugzilla.xfce.org/show_bug.cgi?id=12345)**
## Description
In the Trash folder, you can sort by everything except delete date. Can you please add it as an option - thanks.Xfce 4.18https://gitlab.xfce.org/xfce/thunar/-/issues/914Recursive search much slower after image preview sidepane addition2022-10-27T21:03:39ZAndrew ChadwickRecursive search much slower after image preview sidepane addition## Summary
Since 70cddc4b11644eed3c049c52bf303481cb8104c2, searches take a very long time to start up when the root folder for the search is particularly big. It's always been... not great... but it gets approximately 2-3 times worse wi...## Summary
Since 70cddc4b11644eed3c049c52bf303481cb8104c2, searches take a very long time to start up when the root folder for the search is particularly big. It's always been... not great... but it gets approximately 2-3 times worse with this particular commit.
Note that this is a freeze, a UI lock-up. This can be demonstrated by trying to resize the window during the longer pauses: it doesn't redraw until whatever it was doing in the Gtk UI thread finishes.
## Steps to reproduce
1. Browse to a folder with 3000+ subfolders, for example `/usr/share/doc` on my system
2. Press <kbd>Ctrl+F</kbd> to start a search
3. Type in a search string
4. Wait (this bit varies)
## Symptoms
* No response for several seconds before the search box and entry cursor is shown
* Very laggy typing
## Expectations
* Instant response to starting a search. The pathbar should change instantly, and show a cursor for text entry.
* No typing lag
## Observations
All slowdowns I've seen seem to be unaffected by priming the in-memory file system cache with the tree's content. The cache can be primed by going to `/usr` first and searching for something before testing with wider subfolders deeper in.
I'm using tumblerd 4.17.2 from Debian experimental, and I purge my thumbnail cache and restart tumblerd before each test cycle to keep things consistent. I don't think this one is caused by tumblerd, however!
The typing lag seems to be dependent on the number of search results currently visible, and even the "unaffected" commit I tested below has a bit of this. The affected commits are however much laggier.
## Output
<details><summary>Sample timings</summary>
Sample timings on my NVME laptop local storage for commit 70cddc4b11644eed3c049c52bf303481cb8104c2 (and the current HEAD on main too, 274f43f939462d5d1991627214a6275b501b57a5):
* `/usr`, 12 folders: instant response to <kbd>Ctrl+F</kbd>, no lag in typing
* `/usr/share`, 461 folders: 2 seconds response, appreciable (~1s) lag in typing
* `/usr/share/doc`, 3849 folders: ~8 seconds response, multiple seconds typing lag
For the "unaffected" preceding commit, 3659d451c54116fb41e6cb324f01e274fe785af8, the timings on my system are
* `/usr`, 12 folders: instant response to <kbd>Ctrl+F</kbd>, low typing lag
* `/usr/share`, 461 folders: ~1 second response, typing lag feels worse?
* `/usr/share/doc`, 3849 folders: ~3 seconds response, slight typing lag
</details>
<details><summary>Sample bisect</summary>
```git bisect
git bisect start
# bad: [274f43f939462d5d1991627214a6275b501b57a5] I18n: Update translation is (75%).
git bisect bad 274f43f939462d5d1991627214a6275b501b57a5
# good: [4a36de471beb142047d3fa80391babef8db8cc04] Add posibillity to set custom color to specific files (Issue: #160)
git bisect good 4a36de471beb142047d3fa80391babef8db8cc04
# good: [141d0d420098f0ad304d017118f09b15a15cd2e7] I18n: Update translation vi (73%).
git bisect good 141d0d420098f0ad304d017118f09b15a15cd2e7
# good: [14caba741abe194c1762b6da02ad04b2fe92f577] I18n: Update translation da (93%).
git bisect good 14caba741abe194c1762b6da02ad04b2fe92f577
# good: [86427849615744660cb4edc211ff3f8e614ad101] I18n: Update translation vi (72%).
git bisect good 86427849615744660cb4edc211ff3f8e614ad101
# good: [d35133e5a36e2574f0a691f94d6d8f88aeb2ef23] I18n: Update translation sv (99%).
git bisect good d35133e5a36e2574f0a691f94d6d8f88aeb2ef23
# bad: [1f0f54bcfae89e9d783f828a2dcfa68289483655] Introduce separate class for 'thunar-job-operation-history'
git bisect bad 1f0f54bcfae89e9d783f828a2dcfa68289483655
# bad: [c40006de5c13ce14d40e0aaae6e85d65e926fb03] Shorten wait time to show file transfer rate (Issue #888)
git bisect bad c40006de5c13ce14d40e0aaae6e85d65e926fb03
# good: [87e3c780593b9699ded7052c3ad4a58e740fac08] Limit size of undo/redo history (issue #819)
git bisect good 87e3c780593b9699ded7052c3ad4a58e740fac08
# bad: [70cddc4b11644eed3c049c52bf303481cb8104c2] Image preview sidepane (Issue #357)
git bisect bad 70cddc4b11644eed3c049c52bf303481cb8104c2
# good: [3659d451c54116fb41e6cb324f01e274fe785af8] Prevent GLib-GIO-CRITICAL messages if 'file_>info' is not set
git bisect good 3659d451c54116fb41e6cb324f01e274fe785af8
# first bad commit: [70cddc4b11644eed3c049c52bf303481cb8104c2] Image preview sidepane (Issue #357)
```
</details>Xfce 4.18https://gitlab.xfce.org/xfce/thunar/-/issues/908Suppress delete confirmation dialog on undo/redo2022-10-24T21:21:28ZPratyaksh GautamSuppress delete confirmation dialog on undo/redoWhen a permanent delete is performed, a confirmation dialog is displayed to the user. This dialog is also presented when a delete is triggered by an undo/redo operation. We should suppress this dialog in that case however, since the file...When a permanent delete is performed, a confirmation dialog is displayed to the user. This dialog is also presented when a delete is triggered by an undo/redo operation. We should suppress this dialog in that case however, since the file can be retrieved by just performing a redo/undo, and the dialog just gets in the way.
See #819Xfce 4.18Pratyaksh GautamPratyaksh Gautamhttps://gitlab.xfce.org/xfce/thunar/-/issues/903Add pop-up notification (toast) for undo/redo2022-10-17T07:05:26ZPratyaksh GautamAdd pop-up notification (toast) for undo/redoA small pop-up notification that times out on its own should be added on the user performing an undo/redo.
See https://gitlab.xfce.org/xfce/thunar/-/issues/819#note_51642.A small pop-up notification that times out on its own should be added on the user performing an undo/redo.
See https://gitlab.xfce.org/xfce/thunar/-/issues/819#note_51642.Xfce 4.18Pratyaksh GautamPratyaksh Gautamhttps://gitlab.xfce.org/xfce/thunar/-/issues/782Searching messes up the "special column" logic.2022-05-22T19:23:42ZSergios - Anestis Kefalidisskefalidis@xfce.orgSearching messes up the "special column" logic.There are a few special columns in Thunar, like 'Location' and 'Recency'. Initiating a search and then switching folder can cause these columns to not disappear as they should.There are a few special columns in Thunar, like 'Location' and 'Recency'. Initiating a search and then switching folder can cause these columns to not disappear as they should.Xfce 4.18Sergios - Anestis Kefalidisskefalidis@xfce.orgSergios - Anestis Kefalidisskefalidis@xfce.orghttps://gitlab.xfce.org/xfce/thunar/-/issues/771Make THUNARX_DIRS compile-time2022-05-20T09:49:49ZYves-Alexis PerezMake THUNARX_DIRS compile-timeHi,
looking at the recently released 4.17.8 I noticed the fix for #748 which adds a way to make thunar load plugins from user-supplied directories through an environment variable.
I can understand the need to have plugins in other direc...Hi,
looking at the recently released 4.17.8 I noticed the fix for #748 which adds a way to make thunar load plugins from user-supplied directories through an environment variable.
I can understand the need to have plugins in other directories (in Debian we actually carry a patch so plugins can be loaded from the multiarch dir /usr/lib/<triplet> or from non multiarch /usr/lib/thunarx-3: https://sources.debian.org/src/thunar/4.17.7-1/debian/patches/01_support-non-multiarch-modules.patch/) but I'm a bit annoyed by the fact that it's user-provided from an env var.
For security reason I think where Thunar can load code from should be fixed at compile time (which I think would still work for #748) and not runtime, so this can't be abused. I don't have examples handy but I think it's better to be safe than sorry.Xfce 4.18https://gitlab.xfce.org/xfce/thunar/-/issues/605Trash infobar makes tabs jumping up and down2022-04-07T19:39:00ZAlexander SchwinnTrash infobar makes tabs jumping up and downWhen having several tabs open, one of them beeing trash, than cycling through the tabs will be annoying, since once trash is opened, the tabs will jump up/down because of the new trash infobar.
Because of that, I think we need to reloca...When having several tabs open, one of them beeing trash, than cycling through the tabs will be annoying, since once trash is opened, the tabs will jump up/down because of the new trash infobar.
Because of that, I think we need to relocate the trash infobar inside the tab, not on the top of all tabs.
The infobar was introduced by !78Xfce 4.18Alexander SchwinnAlexander Schwinnhttps://gitlab.xfce.org/xfce/thunar/-/issues/607Make toolbar configureable2022-04-02T21:24:02ZYousuf PhilipsMake toolbar configureableIt would be useful to be able to configure the controls in the toolbar, so they could be show/hidden, reorganized and added/removed.
The functionality to edit the toolbar can work similar to the xfce panel, where you right-click and a c...It would be useful to be able to configure the controls in the toolbar, so they could be show/hidden, reorganized and added/removed.
The functionality to edit the toolbar can work similar to the xfce panel, where you right-click and a context menu appears which give you a menu item for this option. The option would also need to be accessible in the View menu.
SMPlayer screenshot
![image](/uploads/5c8074ef3e3d3e0e13679c1a7dbff872/image.png)
The option can open a dedicated standalone dialog for configuring the toolbar.
SMPlayer
![image](/uploads/b62b03104e73febf2ae4c6e5e4f33a1a/image.png)
LibreOffice
![image](/uploads/b9778cac48f71a2dab5f9cf3ad8d1153/image.png)
Related bugzilla bugs.
[Bug 5921: Feature request: Reload and Home Toolbar icons removed](https://bugzilla.xfce.org/show_bug.cgi?id=5921)
[Bug 11589: Easy access to change the file view and zoom level from the toolbar](https://bugzilla.xfce.org/show_bug.cgi?id=11589)
[Bug 14911: Disabling/Configuring thunar-toolbar](https://bugzilla.xfce.org/show_bug.cgi?id=14911)Xfce 4.18Sergios - Anestis Kefalidisskefalidis@xfce.orgSergios - Anestis Kefalidisskefalidis@xfce.orghttps://gitlab.xfce.org/xfce/thunar/-/issues/694Normal thumbnails generated even if shared thumbnails are available2022-03-09T22:48:09ZAlexander SchwinnNormal thumbnails generated even if shared thumbnails are availableOn viewing a picture folder, shared thumbnails will be used if available (and if there are no normal thumbnails for the folder).
Though since thunar will create normal thumbnails, a f5 will not load the shared thumbnails any more, but f...On viewing a picture folder, shared thumbnails will be used if available (and if there are no normal thumbnails for the folder).
Though since thunar will create normal thumbnails, a f5 will not load the shared thumbnails any more, but favour the normal thumbnails (which is the right thing to do).
Here a small reproducer (for normal sized thumbnails): [shared_thumbnail_test.tar.gz](/uploads/6616f2b7c6bda12f882a040773c336a0/shared_thumbnail_test.tar.gz)
The shared thumbnail of the wallpaper has a "S" painted on it .. so if you see that, you know the shared thumbnails are used.Xfce 4.18