Bug 462845 - The default button changed to Cancel at permanent delete
Summary: The default button changed to Cancel at permanent delete
Status: RESOLVED FIXED
Alias: None
Product: dolphin
Classification: Applications
Component: general (show other bugs)
Version: 22.12.0
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Dolphin Bug Assignee
URL:
Keywords: regression, usability
: 462985 463611 463631 464249 (view as bug list)
Depends on:
Blocks:
 
Reported: 2022-12-10 11:59 UTC by Nick Stefanov
Modified: 2023-09-03 02:55 UTC (History)
21 users (show)

See Also:
Latest Commit:
Version Fixed In: 22.12.1


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Stefanov 2022-12-10 11:59:42 UTC
SUMMARY
When one try to delete a file/folder permanently with Shift+Del, pressing Enter cancels the operation due to the fact that the default button changed to Cancel. Now we have to use the mouse or additional keyboard action to delete the file/folder. I delete MANY files a day and this is very frustrating.


STEPS TO REPRODUCE
1. Shift+Del to delete a file
2. 
3. 

OBSERVED RESULT
The default active button is Cancel.

EXPECTED RESULT
It should be the Delete button as it was untill now.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Arch Linux
KDE Plasma Version: 5.26.4
KDE Frameworks Version: 5.100.0
Qt Version: 5.15.7
Comment 1 Prajna Sariputra 2022-12-10 14:31:29 UTC
In my case the reason I like the old behaviour of preselecting the "Delete Permanently" button in the dialog is that I am using the dialog to quickly double check that I have selected the correct file(s) before confirming, so making the default become "Cancel" now just feels like it adds an unnecessary step, especially while using the keyboard, and making the dialog go away completely with the "Do not ask again" option is also inadequate for me since then I have no simple way to see all the files being deleted by name (especially when the files to be deleted aren't just next to each other in the main view).

Now while I guess I can get used to either the extra step with the dialog, double checking before pressing Shift+Del or forcing myself to actually use the trash folder I don't think messing with muscle memory on a destructive action like this is a good idea, since the adaptation phase now carries a risk of data loss depending on the approach taken, or just unnecessarily nervewracking.

Plus, unlike for example closing Kate or other apps while having unsaved changes (which I notice does also default to "Cancel", so I'm guessing the change for Dolphin was partly made for consistency?), permanently deleting files is something I usually do not only with intention but also a lot more often, while the former almost never happens intentionally for me, and in fact I hardly ever saw that dialog since it's also muscle memory for me to save before exiting.
Comment 2 Nick Stefanov 2022-12-10 17:40:20 UTC
Yes, it's muscle memory and it's hard to get used to a new additional step. I think it's an unintentional behaviour and by accident so I hope it'll be fixed soon. It's worth nothing the Delete button is by default literally everywhere - every single file manager and even Windows Explorer. This is for decades and for a reason.
Comment 3 Patrick Silva 2022-12-10 18:41:05 UTC
There is an inconsistency too. The default button is still 'delete' for files/folders on desktop.
Comment 4 Removed 2022-12-10 19:41:49 UTC
(In reply to Patrick Silva from comment #3)
> There is an inconsistency too. The default button is still 'delete' for
> files/folders on desktop.

No, it's consinstant, it's just because it's dolphin specific.
Desktop is part of plasmashell.
Comment 5 Friedrich W. H. Kossebau 2022-12-10 21:14:37 UTC
Related commits changing the behaviour:
* https://invent.kde.org/system/dolphin/-/merge_requests/462
* https://invent.kde.org/frameworks/kio/-/merge_requests/1005
Comment 6 Dashon 2022-12-12 17:58:11 UTC
I also just noticed this. Like do we really need to baby users this much? You have to use a different shortcut for delete, then you have to go through the pop up and now they need to select to confirm the delete. If they can't pay attention during the first two steps. I have no hope they will do so on the third step either. Just adding one more step to the process for everyone else.
Comment 7 Removed 2022-12-12 19:49:46 UTC
(In reply to Dashon from comment #6)
> I also just noticed this. Like do we really need to baby users this much?
> You have to use a different shortcut for delete, then you have to go through
> the pop up and now they need to select to confirm the delete. If they can't
> pay attention during the first two steps. I have no hope they will do so on
> the third step either. Just adding one more step to the process for everyone
> else.

I absolutely agree with you.
And If you still want to do it, just let others disable this functionality.
Comment 8 Paul Worrall 2022-12-13 09:15:04 UTC
*** Bug 462985 has been marked as a duplicate of this bug. ***
Comment 9 AlexLG 2022-12-13 10:06:34 UTC
Hello, I can confirm that after 20+ years using this functionality, the change in default behavior is very disturbing.

I also don't think it's really necessary, but can we at least have an option to retrieve the previous behavior ?
Comment 10 Alex 2022-12-13 10:18:15 UTC
I don't why this change was made. The user already makes an implicit confirmation by pressing the shift key.
Comment 11 Nick Stefanov 2022-12-13 10:39:21 UTC
Some people think KDE Plasma is a testing pilot or a hobby. No, it's my full time work horse and now my workflow is broken. I'm pissed off from such "improvements". Let's focus on fixing bugs, not such "improvements", KDE needs this badly.
Comment 12 Christian (Fuchs) 2022-12-13 22:28:27 UTC
+1 for a revert, as just explained in the VDG group, this change is imho bad on multiple levels.

The argument brought of "handling destructive actions differently than non-destructive ones"  does not work on multiple levels. Because it will be inconsistent between apps that do differentiate between delete and permanently delete, so the same action (delete) behaves differently depending on the app. People used to "switch button then enter" and use the keyboard will now get delete permanently for the same action that used to be cancel for ages or in different apps. So the chance to accidentally delete stuff for good is actually increased for keyboard users.
Comment 13 Peter Tselios 2022-12-14 08:02:14 UTC
I second all comments. 
First, I honestly believe that developers spend their energy to non-useful "improvements". They spend time to "improve" non-broken things, then they spend more time to revert them. 

Then, we have a decision about this. There is no sane argument about "safety", it's already too safe! In any case, please revert the change.
Comment 14 Felix Ernst 2022-12-14 12:53:02 UTC
I agree! We should have kept the old behaviour unless there was a big discussion about this. The thing is: This never was an intentional change!

(In reply to Nick Stefanov from comment #11)
> Some people think KDE Plasma is a testing pilot or a hobby. No, it's my full
> time work horse and now my workflow is broken. I'm pissed off from such
> "improvements". Let's focus on fixing bugs, not such "improvements", KDE
> needs this badly.
(In reply to Peter Tselios from comment #13)
> First, I honestly believe that developers spend their energy to non-useful
> "improvements". They spend time to "improve" non-broken things, then they
> spend more time to revert them. 

I am sure you will be glad to hear then that this behaviour change happened as a side-effect of fixing https://bugs.kde.org/show_bug.cgi?id=431351. Your assumptions about this being an ill-conceived attempt of improving something that didn't need improving is therefore wrong. Your annoyance is also misplaced: We simply don't have enough volunteers or money to make sure that such things never happen.

Now let's get back to solving the problem instead of venting.
Comment 15 Bug Janitor Service 2022-12-14 13:05:11 UTC
A possibly relevant merge request was started @ https://invent.kde.org/system/dolphin/-/merge_requests/480
Comment 16 Alex 2022-12-14 13:11:07 UTC
(In reply to Felix Ernst from comment #14)
> I agree! We should have kept the old behaviour unless there was a big
> discussion about this. The thing is: This never was an intentional change!
> 
> (In reply to Nick Stefanov from comment #11)
> > Some people think KDE Plasma is a testing pilot or a hobby. No, it's my full
> > time work horse and now my workflow is broken. I'm pissed off from such
> > "improvements". Let's focus on fixing bugs, not such "improvements", KDE
> > needs this badly.
> (In reply to Peter Tselios from comment #13)
> > First, I honestly believe that developers spend their energy to non-useful
> > "improvements". They spend time to "improve" non-broken things, then they
> > spend more time to revert them. 
> 
> I am sure you will be glad to hear then that this behaviour change happened
> as a side-effect of fixing https://bugs.kde.org/show_bug.cgi?id=431351. Your
> assumptions about this being an ill-conceived attempt of improving something
> that didn't need improving is therefore wrong. Your annoyance is also
> misplaced: We simply don't have enough volunteers or money to make sure that
> such things never happen.
> 
> Now let's get back to solving the problem instead of venting.

Glad to read this. Thank you for your work!
Comment 17 AlexLG 2022-12-14 15:21:23 UTC
Thanks Felix for the reply, glad to see it's a regression 😅 Thanks for the revert (and the enhancement for after)!
Comment 18 BOF 2022-12-15 13:34:21 UTC
I noticed this as well and I'm also not a fan of it...

... even thought it makes much more sense to have the default action of "delete permanently" to be "no" instead of "yes".
However I think that
1) the default behaviour should be customisable (I mean it's still the you-change-this-setting KDE, right?) 
2) There could be a shortcut like Shift+Del brings you to the menu and Ctrl+Enter is "Yes"
Comment 19 Sebastian Gauna 2022-12-16 06:40:39 UTC
This was a terrible change to me, glad it wasn't intentional, I hope it'll be reverted soon.
Comment 20 Bug Janitor Service 2022-12-19 23:31:03 UTC
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kio/-/merge_requests/1088
Comment 21 Friedrich W. H. Kossebau 2022-12-20 00:18:06 UTC
(In reply to Friedrich W. H. Kossebau from comment #5)
> Related commits changing the behaviour:
> * https://invent.kde.org/system/dolphin/-/merge_requests/462
> * https://invent.kde.org/frameworks/kio/-/merge_requests/1005

The latter was a wrong read, actually on the KIO side things were changed in
* https://invent.kde.org/frameworks/kio/-/merge_requests/818
Comment 22 Nate Graham 2022-12-23 19:44:36 UTC
https://invent.kde.org/system/dolphin/-/merge_requests/480 was merged by Felix Ernst for Dolphin 22.12.1, which fixes this.
Comment 23 Felix Ernst 2022-12-30 12:13:25 UTC
Git commit da081e8bd5d9fcea672c561dc23293ccf043e3e6 by Felix Ernst.
Committed on 30/12/2022 at 12:13.
Pushed by felixernst into branch 'master'.

Pre-select "Delete" in Delete Confirmation Dialog

This commit makes the "Delete" button the default button in the dialog
for confirming direct deletion of a file and in the dialog for
confirming emptying of the trash.

This was accidentally changed in
8144733c5110c66922381f97829f9470b26c8122 while trying to change the
dialog styling to be more like a warning. Users were unhappy about this
because it broke their muscle memory of "Shift+Del" into "Return" to
permanently delete a file.

This "revert" changes the dialog type from "warning" back to
"question". However, this would also change the icon displayed in the
dialog so the icon is explicitly set to be the same as in the "warning"
dialog.

An alternative suggestion was to add explicit API to select the
pre-selected button but this didn't happen as part of this "revert".

M  +7    -4    src/widgets/widgetsaskuseractionhandler.cpp

https://invent.kde.org/frameworks/kio/commit/da081e8bd5d9fcea672c561dc23293ccf043e3e6
Comment 24 Felix Ernst 2022-12-30 13:54:29 UTC
*** Bug 463611 has been marked as a duplicate of this bug. ***
Comment 25 Nicolas Fella 2022-12-31 01:08:55 UTC
*** Bug 463631 has been marked as a duplicate of this bug. ***
Comment 26 Patrick Silva 2023-01-13 21:35:08 UTC
*** Bug 464249 has been marked as a duplicate of this bug. ***