Why is it essential ? Why do you care if the files you deleted linger around in the trash for a while ? Are you aware that Shift-Delete still works to bypass the trash ?

Essential because the trash began to fill up a lot of disk space very rapidly. On a rather small SSD this makes a huge difference if 5 GB are freed or just moved.

Yes, I am aware of the shortcut however I tend to use the mouse more often and I think one does not have to argue that a hidden shortcut is not userfriendly.
I can not think of any reason why one should remove a working function. It does not harm anyone as it only was in opt-in option the settings.

What is a non hidden shortcut? 
("userfriendly" is a word used for anything nowadays. It's not userfriendly either to provide lots and lots of potentially uncommon options via a User interface...)

Guess you are right, userfriendly is nowadays often misused. However I do think that this option is anything but unnecessary. It saves a lot of disk space for people who work on rather small partitions like on an SSD.
Furthermore I  do not think that nautilus' option-page is overloaded. This is only my personal opinion and I can understand if people see that differently.

Btw. a hidden shortcut to me is something that can not be found when just digging through the settings although being present. Like an option which is there and already works (alt+del) but is only found out when e.g. googling.

> In a rather small SSD this makes a huge difference if 5 GB are freed or just moved.

You should receive a notification if space gets used up, offering you to empty the trash. Has that happened to you ?

Another way to address your problem is to go the the privacy panel, "Purge trash and temporary files", and configure the system to purge the trash agressively.

What's the rationale for removing the right-click delete capability entirely (as opposed to making sure it can only be enabled by users who know its consequences)? Is there a bug report for that with more details? I can't find it.

If it's to prevent the average user from accidentally irrecoverably deleting files, this is already covered in two ways:

* It isn't enabled by default. The user must actively change a setting in Nautilus's preferences.
* When the context menu item is clicked, the use is shown a confirmation dialogue.

If there is a concern that this is still not enough, and an average user could somehow conceivably get past both of the above, then leaving it as a Dconf option will guarantee that doesn't happen.

Having this removed entirely doesn't actually protect any real users I suspect.

In regard to the "just use the keyboard shortcut" suggestion: if the user has 'single-click to open' enabled, using a keyboard shortcut to delete is much more cumbersome, as they have to then ctrl-click to select the file (assuming they don't have other files/folders currently selected, which adds more complication and further clicks), then shift-delete - a minimum of at least four clicks excluding confirmation., vs. two for right-click delete.

(In reply to Stephen from comment #6)
> What's the rationale for removing the right-click delete capability entirely
> (as opposed to making sure it can only be enabled by users who know its
> consequences)? Is there a bug report for that with more details? I can't
> find it.
> 
> If it's to prevent the average user from accidentally irrecoverably deleting
> files, this is already covered in two ways:
> 
> * It isn't enabled by default. The user must actively change a setting in
> Nautilus's preferences.
> * When the context menu item is clicked, the use is shown a confirmation
> dialogue.
> 
> If there is a concern that this is still not enough, and an average user
> could somehow conceivably get past both of the above, then leaving it as a
> Dconf option will guarantee that doesn't happen.
> 
> Having this removed entirely doesn't actually protect any real users I
> suspect.
There is no bug report for this change, so I will try to explain here.

The rationale is that is confusing having two deletes in the same menu. Although we changed the "Delete" to "Move to Trash" it is still confusing and dangerous.

You are right tho, that if we don't enable by default and allow power users to enable it by dconf it won't be a problem and thinking like you I implemented that for 3.15. But I was wrong, power users started complaining that they can't longer delete by the shortcut shift+delete to delete permanently. An I pointed to them that it needs to be enabled in dconf and they were angry.

So my final solution was to allow the shortcut always (since that from 3.16 the move to trash shortcut is no longer ctrl+del which can be problematic if you move your finger to shift+del) but don't put a menu item that can be confusing.

I think this is the best trade off I came with after implementing and testing all the other options.

Hi Carlos, thanks for the response!

Confusing for whom though? Users who explicitly enable it in Nautilus preferences? If that's believed to be the case the case, then it should be possible at least to enable it in dconf still. It is guaranteed not to be confusing for the sort of user who knows how to do that!

Having the dconf org.gnome.nautilus.preferences.enable-delete toggle cover the menu item would cover the use cases of both the 'angry power users' ;) you mention as well as those currently using the menu entry, while avoiding entirely confusing the less technical class of users (since it's in dconf only).

There doesn't have to be a trade-off here I think:

* Shift-delete enabled by default
* Menu entry disabled by default, enabled via dconf

Everyone is (more) happy than now, non-technical users are safe, win-win :)

If I'm missing something, let me know!

(In reply to Stephen from comment #9)
> Hi Carlos, thanks for the response!
> 
> Confusing for whom though? Users who explicitly enable it in Nautilus
> preferences? If that's believed to be the case the case, then it should be
> possible at least to enable it in dconf still. It is guaranteed not to be
> confusing for the sort of user who knows how to do that!
> 
> Having the dconf org.gnome.nautilus.preferences.enable-delete toggle cover
> the menu item would cover the use cases of both the 'angry power users' ;)
> you mention as well as those currently using the menu entry, while avoiding
> entirely confusing the less technical class of users (since it's in dconf
> only).
> 
> There doesn't have to be a trade-off here I think:
> 
> * Shift-delete enabled by default
> * Menu entry disabled by default, enabled via dconf
> 
> Everyone is (more) happy than now, non-technical users are safe, win-win :)
> 
> If I'm missing something, let me know!

Fair enough, I will accept a patch for a preference for that in dconf since I don't want for some users exploring the preferences menu to hit this  (and we can back port it to 3.16 since there is not default UI change)

(In reply to Carlos Soriano from comment #10)
> (and we can back port it to 3.16 since there is not default UI change)

Only after a string freeze break request approval. dconf strings are strings.

(In reply to André Klapper from comment #11)
> (In reply to Carlos Soriano from comment #10)
> > (and we can back port it to 3.16 since there is not default UI change)
> 
> Only after a string freeze break request approval. dconf strings are strings.

oh ok, thanks for pointing out

I'm not in a position to write that patch at the moment though in terms of time, expertise or familiarity with the code...!

What are the chances of one of the devs on this bug report adding it to their to-do list maybe? :)

removing the 3.16 target, just wait until someone interested implements it.

It's a bit unfortunate that this change was made without much communication that might be picked up by users in advance (e.g. blog posts). Had that happened, the post-implementation feedback provided/issues raised above could have been taken into account before implementing the related changes.

As it is, a capability that is potentially taken advantage of by a significant number of users (I don't have stats to back up this assertion, but were any stats to show otherwise gathered beforehand?) has been lost, and has now become something that won't be restored until "someone interested implements it."

An end user (most people falling under "someone interested") does not have the benefit of familiarity with the Nautilus code base, languages and style and any other number of requisites for fixing this and getting it included - the amount of time it would take them is an order of magnitude greater than it would take one of the core Nautilus devs.

(In reply to Stephen from comment #15)
> It's a bit unfortunate that this change was made without much communication
> that might be picked up by users in advance (e.g. blog posts). Had that
> happened, the post-implementation feedback provided/issues raised above
> could have been taken into account before implementing the related changes.
> 
> As it is, a capability that is potentially taken advantage of by a
> significant number of users (I don't have stats to back up this assertion,
> but were any stats to show otherwise gathered beforehand?) has been lost,
> and has now become something that won't be restored until "someone
> interested implements it."
> 
> An end user (most people falling under "someone interested") does not have
> the benefit of familiarity with the Nautilus code base, languages and style
> and any other number of requisites for fixing this and getting it included -
> the amount of time it would take them is an order of magnitude greater than
> it would take one of the core Nautilus devs.

Bugzilla is not for this kind of discussion, please keep it appropriate. (You can use IRC #nautilus or forums).

Answering you, no one can pretend we post every change, someone can take care of that as well, remember this is a community project, and commits are very well displayed and public in git.gnome.org . Said that I tried to do that on my free time with the changes I believe are important enough (writing a post with pictures and correct English is time consuming, done in my free time, and I think developing is already contributing a lot).

As for "is unfortunate waiting for someone interested to implement it", well, if I had to implement everything that comes to Bugzilla, we would need 10 people working on Nautilus (and I would be very happy about it!). Until then, I have to keep my own priorities (and another developer of those 10 can have a different set of priorities which can include this enhancement).

As said, if you want more off-topic discussion, use IRC or forums.

The ideal solution would be to never remove features, as any feature removal will always be a problem for the users.
Having said that, it would not be a problem to implement such option as a DConf setting, but where is this setting documented?
Having a feature that is not documented, or where the documentation is hard to find, is like not having that feature at all.

(In reply to Franco Bugnano from comment #17)
> The ideal solution would be to never remove features, as any feature removal
> will always be a problem for the users.
> Having said that, it would not be a problem to implement such option as a
> DConf setting, but where is this setting documented?
> Having a feature that is not documented, or where the documentation is hard
> to find, is like not having that feature at all.

Hi,

Application evolution, so you need to make changes, and keep everything from the past is usually very difficult and removing is part of the evolution. Said that, in this specific case, I don't see a problem to have it and the maintenance cost is very low with the latest changes we did in master.

But I don't think Preferences deserves a switch for this, since it was confusing before as bug reports shown (you can search for them).

*** This bug has been marked as a duplicate of bug 315022 ***