Bug 100394 - Shift should switch "Move to Trash" to "Delete" and it's icon also
Summary: Shift should switch "Move to Trash" to "Delete" and it's icon also
Status: RESOLVED WORKSFORME
Alias: None
Product: konqueror
Classification: Applications
Component: servicemenus (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Aaron J. Seigo
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-02-27 20:05 UTC by Hugo Rodrigues
Modified: 2007-12-13 02:55 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Hugo Rodrigues 2005-02-27 20:05:42 UTC
Version:           3.4.0 (using KDE 3.4.0 Level "a" , SUSE 9.2 UNSUPPORTED)
Compiler:          gcc version 3.3.4 (pre 3.3.5 20040809)
OS:                Linux (i686) release 2.6.8-24.10-default

Pressing Shift key should switch "Move to Trash" text in the context menu to "Delete" and it's icon also acordingly.
I'm posting this as a bug and not a wishlist because the default behaviour in KDE 3.4.0-rc1 is that only "Move to Trash" is displayed but if you press Shift and click "Move to Trash" it will indeed delete the file/folder instead of the stated "move to the trash" action, and that's misleading to the more unmatured user. There's a warning message after it, mentioning the action to be taken, but only if it's not disabled by the user on Konqueror's "Behaviour" module for Kcontrol.

I like the Shift key feature so please don't remove it. What I sugest is to switch the displayed text and icon of the context menu on-the-fly only when the Shift key is pressed (and switched back if Shift key is released, of course).
This for me is the best way to correct the default behaviour. Now you may say that an unmatured user would not know of the Shift key thing, but he can accidently press it and end up with his file lost for ever. Bug 95102 is also about this issue but it's marked as fixed and the sugestions are not quite the same, worth to read though.
Comment 1 Stephan Binner 2005-04-05 17:18:53 UTC
*** Bug has been marked as fixed ***.
Comment 2 Hugo Rodrigues 2005-06-27 14:58:20 UTC
I'm reopening this bug report since I'm now using KDE 3.4.89 (>=20050615), compiled from SVN on 2005/06/27, and this misleading behabiour is still present.
I don't know why it was marked as RESOLVED since I can't see any difference from when I first posted this bug report.
The icon and text should change acordingly to the state of the Shift key (being pressed or not). Please read the initial bug report above.
Comment 3 Thiago Macieira 2005-06-28 02:36:36 UTC
I'm not sure context menus can be changed on the fly like you requested.
Comment 4 Mike Adams 2005-10-13 15:07:52 UTC
This sort of thing happens on my system using KDE 3.3.2 and Konqueror 3.3.2

According to the right click menu Delete should be move to trash and Shift-Delete should be full Delete but if I do Shift-Delete it will do a move to trash and not full delete.
Comment 5 lexual 2005-10-31 09:30:59 UTC
works for me with kubuntus 3.4.3.
shift right-click gives the delete option.
Comment 6 lexual 2005-10-31 09:42:20 UTC
I had misinterpreted the bug.
If I right-click, then hit the shift key and then select move-to-trash, it will delete file even thought the user hit the move-to-trash option.

So I am confirming, it seems to me either we have to make the menu dynamically changeable, or disable the feature where you can hit the shift key after hitting right-click and the delete option is taken over the move-to-trash one.

I would go for the 2nd one because it all works fine if you do SHIFT-click instead of click->SHIFT.
Comment 7 Hugo Rodrigues 2005-10-31 14:14:59 UTC
Yes, your 2nd choice is the easiest to implement and at least it makes the action coherent with what the menu is showing.
But I would definitly prefer to have your 1st choice implemented in the midle/short run. It implies that our menus have to be changeable on-the-fly (the menu's text and icons would change even with the menu already being displayed), it would make KDE the first to support this usefull behaviour AFAIK.
Comment 8 lexual 2007-12-13 02:55:35 UTC
fixed in kde4.