While configurability is always nice, do note that all shortcuts are standard shortcuts for their purpose, F2 e.g. to rename is ubiquitous - it works in dolphin and many other Qt apps with editable item views, but it also works under Window's Explorer e.g.

In D1523#30919, @mwolff wrote:

While configurability is always nice, do note that all shortcuts are standard shortcuts for their purpose, F2 e.g. to rename is ubiquitous

Evidently ubiquitous doesn't include OS X ;)
Regardless of that, I've been using that F2 mapping I mentioned since well before MS Windows 3 (supposing that's where the F2=Rename mapping originated). F1=Raise, F2=Lower, F5=Minimise etc. might come from DomainOS but could also be a personal choice. Too long ago.

I'm not getting the shortcut changes applied through an actionCollection() to work. They show up, and I do get conflict warnings about Key_Delete until I change the shortcut on the Project Manager's "Remove..." action. But for some reason the old shortcuts remain active.

I've also realised that these shortcuts are apparently enabled only when the project manager has focus, so not when you're editing a file for instance. That's logical, but IMHO it also means that there's a lot less point in having shortcuts. Shortcuts are extremely useful if they can prevent you from having to go for the mouse, but if you're already using the mouse instead of the keyboard you can almost apply the opposite argument. IOW, I'm now running a local patch which removes the F2 shortcut (just use a right-click to select a file to be renamed and use the context menu). It also remaps the Remove shortcut to the one used in the Finder; that could of course be a Mac-specific change.

diff --git plugins/projectmanagerview/projectmanagerview.cpp plugins/projectmanagerview/projectmanagerview.cpp
index f08fe23..e8eeca1 100644
--- plugins/projectmanagerview/projectmanagerview.cpp
+++ plugins/projectmanagerview/projectmanagerview.cpp
@@ -146,12 +146,12 @@ bool ProjectManagerView::eventFilter(QObject* obj, QEvent* event)
     if (obj == m_ui->projectTreeView) {
         if (event->type() == QEvent::KeyRelease) {
             QKeyEvent* keyEvent = static_cast<QKeyEvent*>(event);
-            if (keyEvent->key() == Qt::Key_Delete && keyEvent->modifiers() == Qt::NoModifier) {
+            if (keyEvent->key() == Qt:: Key_Backspace && keyEvent->modifiers() == Qt::ControlModifier) {
                 m_plugin->removeItems(selectedItems());
                 return true;
-            } else if (keyEvent->key() == Qt::Key_F2 && keyEvent->modifiers() == Qt::NoModifier) {
-                m_plugin->renameItems(selectedItems());
-                return true;
+//             } else if (keyEvent->key() == Qt::Key_F2 && keyEvent->modifiers() == Qt::NoModifier) {
+//                 m_plugin->renameItems(selectedItems());
+//                 return true;
             } else if (keyEvent->key() == Qt::Key_C && keyEvent->modifiers() == Qt::ControlModifier) {
                 m_plugin->copyFromContextMenu();
                 return true;

Agreed.

I presume you're running a Plasma5 desktop; could you check if KWin5 and/or kglobalacceld still propagate keystrokes (like F2) that are custom shortcuts for KWin actions as described in the summary for KWin4? I guess that's actually the underlying issue.

In D1523#87467, @mwolff wrote:

In general, I think solving this in KDevelop is the wrong place.

Did you see the thread I started on the frameworks ML? KDevelop *might* be the right place after all, unless there's a specific reason why ProjectManagerView::eventFilter() uses KeyRelease instead of KeyPress?

I could imagine using KeyRelease for dangerous actions like Delete that may not post a confirmation dialog, so that users can back out by pressing an additional key before releasing, say, the Backspace key. But actions like rename that will always post a dialog can just as well be triggered by KeyPress events.

This would be a much simpler mod that should be almost transparent from the ("normal") user's point of view: