In the "Édition" (French) menu or into the contextual menu when right-clicking on a file or folder, we have 2 actions : - move to trash - delete I think it is confusing of the end user or it brings to cognitive overload for advanced users. I think that both aren't desirable in a desktop environment which is "visually appealing and user friendly". Maybe an setting could provide the below choices for the end user : - show only "move to trash" (by default as traditional desktop paradigm) - show only "delete" - show both "move to trash" and "delete"
Created attachment 6979 2 near entries are error prone Moreover, the 2 entries are near and thus an error can easily occur when choosing "delete" instead of "move to trash".
Sorry for the late reply ! I totally agree with you that this should be configurable. IMO the default should be to only have " move to trash", but that I have to discuss with the other developers first.
Did you plan a bug fix into the next release ?
It's on my personal TODO List .. but sadly this list is rather long
While we are waiting for a new user option into a configuration tool, could we possibly hide the "remove" action from the contextual menu as a temporary workaround ? Anyway, when the new configuration tool will be available, the comment #2 suggests it should be the default behaviour of the menu.
Not that easy. "move to trash" is only available when gvfs is installed. But gvfs is optional. The internal logic should be: If "move to trash" is selected, but gvfs is not installed: Display an error on startup and provide at least "delete". The configuration menu should only allow to select "move to trash" when gvfs is installed. ( And ofc provide some info why "move to trash" cannot be selected if gfvs is not available ) ... doable, but there will be no quick workaround due to this.
Created attachment 7916 add preferences item to control delete / move to trash Finally I found some time to look into it. Please take a try for the patch if you can, and let me know if you like it. I as well pushed my local branch to github to ease code review: https://github.com/alexxcons/thunar/commit/f9ff6bb2380b0a311650dcfd9ddedfb6f7bcc4ac
I read your code review page. It seems great. Thanks a lot :)
I'll be direct: speaking of "cognitive overload" when two options that are similar/related are next to each other seems a bit drastic. I think it's very obvious what will happen in each case and mis-clicking can happen in any other context too. I mean cut and copy are also next to each other. Also, mis-clicking isn't really a problem in this context: after all deleting spawns a confirmation dialog. And clicking "move to trash" by accident will not delete the file (and if that was your intention it probably also doesn't really hurt). If I look at the other options in the "Advanced" tab this one seems oddly granular and doesn't fit. Compare the hiding of a single context menu entry to enabling/disabling volume management or handling folder permissions. Both have a much higher functional impact. If anything I would implement this as a hidden option. But again, even this I would consider overkill, especially as Thunar's source isn't exactly lean, short and super-maintainable. (And finally: We really have bigger fish to fry...) </my2cents>
@Simon Sorry, I should have further explained my motivation on this issue in the first place. I personally had trouble with "delete/move to trash". > I think it's very obvious what will happen in each case Not in all situations. E.g. if gvfs is not installed (in thunar it is optional), you only will see 'Delete', and unless you search the web, you will not realize at all that thunar supports "Trash" besides 'Delete'. Users may expect trash behavior, and wonder about the dialog. IMO a preferences option will give at least a chance to figure out what is "wrong". > and mis-clicking can happen in any other context too. I mean cut and copy are also next to each other. I think the problem is not exactly mis-clicking, but more like "I dont care, I just want to get this file out of the way now" and later regretting to have chosen the wrong action. > Also, mis-clicking isn't really a problem in this context: after all deleting spawns a confirmation dialog. Way back I clicked 'ok' on it just like a reflex ... think I do so on most 'do you realy want?' dialogs. Iirc, I did not have gvfs installed at that point. > If I look at the other options in the "Advanced" tab this one seems oddly granular and doesn't fit. True, it has a more granular nature than the others, we could move it e.g. to "Behavior". > If anything I would implement this as a hidden option. Since gvfs is optional in thunar, I disagree. "move to trash" is the standard way to dump files nowadays. If "move to trash" does not show up, because gvfs got uninstalled, it should be easy to figure out what is wrong, without searching the web for help. A 1-item enum + the tooltip on it hopefully will do. > But again, even this I would consider overkill, especially as Thunar's source isn't exactly lean, short and super-maintainable. No problem here. This features complexity/maintainability impact is almost zero. > (And finally: We really have bigger fish to fry...) I fear there always will be a bigger fish. From time to time I have appetite for small fish. Usually they can be fried quickly. :) The argument "less context menu items" was not mentioned so far: IMO it is more important to have a short context menu than a short preferences dialog, since the context menu is used more frequently.
I may be wrong, but doesn't not having gvfs installed have other implications too - e.g. no browsing of remote locations? To me that's a point of distributors shipping stuff with dependencies (otherwise any app will be broken) or our documentation listing the implications of not having gvfs installed. > IMO a preferences option will give at least a chance to figure out what is "wrong". Your argument seems to be that the option should be there for people to figure out what's wrong. I'm not sure how helpful this option is in this case, it just shows that something is broken/inconsistent in Thunar, because the option will either refer to a context-menu entry that's not there ("Move to trash") or not mention it and not be super-helpful. To me it feels more natural to just document this. I also haven't seen many distros around lately that ship Thunar without gvfs integration and users that decide to build their distros simply have to learn about dependencies and their implications. Btw, if the online documentation feels like "not enough" there's also the possibility to add an infobar in the preferences dialog informing the user that gvfs and its features is not available and that the implications can be read about on the web doc. Anyway, it's your call. I remain unconvinced that this is really a helpful option or the right thing to do :)
@alexxcons Perhaps we are making a mountain out of a molehill. Gvfs being or not present is ultimately the responsibility of the distribution, or in the case of minimal distributions such as Arch Linux, users are expected to know what they are doing or are able to figured things out on their own. With regards the unintentional file removal, from time to time I do this mistake using the hotkeys (shift+delete is my default) and I believe most users do not delete/move files to trash using the context menu, so this limits a lot the safety you want to introduce. At the end of the day, I really don't mind you pushing this change, I won't get upset or anything, but before you push, can you please post an updated patch or update that GitHub branch so I can test?
> ... doesn't not having gvfs installed have other implications too - e.g. no browsing of remote locations? Yes, that is the case. > To me that's a point of distributors shipping stuff with dependencies (otherwise any app will be broken) I dont think so. We chose on our own to have it optional, so we have to properly support the possibility that it is not available. If we want to rely on it, we should make it mandatory. > Gvfs being or not present is ultimately the responsibility of the distribution, ... E.g. If I use kde and want to take a try for xfce, I will just install the related packages, which will not pull optional stuff. Using a different DE often does not imply a fresh installation. IMO we need to provide a way to show that something could be added. >... because the option will either refer to a context-menu entry that's not there ("Move to trash") or not mention it and not be super-helpful. "move to trash" will only be shown as combo-value if gvfs is installed. So not having it installed will lead to an enum with only one value. IMO this should be sufficient to tell users that other options are possible, so that they read the tooltip (or the Wiki). > Btw, if the online documentation feels like "not enough" there's also the possibility to add an infobar in the preferences dialog informing the user that gvfs and its features is not available and that the implications can be read about on the web doc. Nice idea! We could as well inform about remote locations ... so it would fit into the "advanced" tab. Drawback: Possibly it could annoy users which explicitly dont want gvfs. > and I believe most users do not delete/move files to trash using the context menu I think most users use the context menu ... guess we tend to expect our own habits from others ;) > Perhaps we are making a mountain out of a molehill. I totally agree! > Anyway, it's your call. I remain unconvinced that this is really a helpful I would prefer to convince you first, but I see that this might be hard to impossible ;-) Maybe we can at least agree that less context menu items is better than less preferences items ? Ok, so let me provide an updated patch for review with the mentioned improvements, in order to get this molehill done ;)
Created attachment 7945 checkbox to toggle delete Ok, here a different approach: - simple checkbox to toggle delete - Default value will depend on if gvfs is installed or not For easy review: https://github.com/alexxcons/thunar/commit/6cc03baf4d4180169a139f3902fe22d1dab374ea - The second patch will show a infobar, but only if there is no trash-support
Created attachment 7946 infobar For easy review: https://github.com/alexxcons/thunar/commit/839d52f271cb9fbf0c6153f6a2c393475d2401d5 Possibly the text could be improved .. any advice is welcome !
Nice work! Regarding the infobar my suggestion would have been to just add a generic mention there like: "Thunar has detected that gvfs-backends is not available. Several features of Thunar including remote location browsing or trash are currently not available. [Read more]" Clicking the read more button would open the website where we can much more easily maintain up-to-date information on e.g. package names in distributions or a complete list of features that depend on gvfs.
Created attachment 7959 infobar Linking the wiki is a good idea ! And make it more general as well. I did not find a way to check if gvfs-backends is available in general, in gio I only can check if specific uri-schemes are supported. So I made the text a bit more "blurry", in case some other gvfs components are missing. Now added checks for removable media and sftp to cover the most important backends. Code + Screenshot: https://github.com/alexxcons/thunar/commit/519367e852d5c997c75d26a06a2a9f2224bb6028
Looks good! With the brackets I wanted to imply an actual GtkButton though - as those can be easily added to infobars :)
Oh, a real button, ok :P I just took a try .. easy to add a button on the right, but that would increase the size of the preferences Menu ... not that nice: https://i.imgur.com/75ClUo3.png I tried to change the orientation of the container, but so far it only worked via gtkinspector. ( tried "gtk_orientable_set_orientation" on the content area ... dont know yet why it does not work ) IMO button below text as well looks not that nice, since the button eats up alot of space: https://i.imgur.com/eeO7DJl.png So before investing more time into such details ... how about we just keep the braces ? ;)
I would rephrase to "It looks like gvfs is not installed (...)", or "available" instead of "installed". "you are missing" is ambiguous, kinda sounds like the user is longing for something. I prefer just "gvfs" because it's more generic and there is no such "gvfs-backends" in Arch Linux land ;) Also s/Several major features of Thunar/Important features/, several and major are a bit of exaggeration, no need to state features of *Thunar*. The button looks too dramatic, I like the plain link most.
As a user, I understand directly that a link opens a web browser with a web page. For a button, I expect some action inside the application (save preference, handle the window, cancel, ...).
Created attachment 7967 infobar @ Andre Miranda Good points ! I took all into account. Plain link is set ! Feels like finally it is ready to get pushed :)
Indeed, well done! (And I agree, the link looks better than the button)
@alexxcons all look good, the changeset is smaller than I expect, which is really nice =) The only small detail I'm not sure is, when gvfs is unavailable, why show the Context menu section if it won't make any difference? Besides that (and the whitespace introduced at the first line of the first patch), IMO it's ready to be pushed. Congrats and thanks!
Alexander Schwinn referenced this bugreport in commit 83c6e26693c1c3e5d328c2f478f9390079093bd2 Add preferences item to toggle the delete in the context menu (Bug #13327) https://git.xfce.org/xfce/thunar/commit?id=83c6e26693c1c3e5d328c2f478f9390079093bd2
Alexander Schwinn referenced this bugreport in commit 5917e7dfb57df71336accc2062b43e861ef0342e Add preferences item to toggle the delete in the context menu (Bug #13327) https://git.xfce.org/xfce/thunar/commit?id=5917e7dfb57df71336accc2062b43e861ef0342e
- removed whitespace, - added logic to add "context menu" only if "trash" is suppported, and show "delete" per default if "trash" is not supported - pushed to master and 4.14, will be released in thunar 1.8.2 Thanks you all for review, testing and as well for the constructive critics !!
Thank you alexxcons, for your superb work and unshakeable patience =)
Thank you alexxcons. I will appreciate your enhancement in the next releases and I assume that a lot of user will find it useful.