Summary: | Shift should switch "Move to Trash" to "Delete" and it's icon also | ||
---|---|---|---|
Product: | [Applications] konqueror | Reporter: | Hugo Rodrigues <rodrigueshugo> |
Component: | servicemenus | Assignee: | Aaron J. Seigo <aseigo> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | lex.lists, madams |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Hugo Rodrigues
2005-02-27 20:05:42 UTC
*** Bug has been marked as fixed ***. 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. I'm not sure context menus can be changed on the fly like you requested. 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. works for me with kubuntus 3.4.3. shift right-click gives the delete option. 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. 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. fixed in kde4. |