Usability/Keyboard: Add a rebindable keyboard shortcut for editing items as a replacement for F2 #13148

cr7pt0gr4ph7 · 2024-04-21T10:42:12Z

Issue Statement

Right now, one cannot easily use a keyboard shortcut to begin editing a track table cell when keyboard shortcuts are enabled, because the usual F2 key is bound to something else by default the default .kbd.cfg files provided.

Use Case

I am currently setting up my music library, and it is quite annoying that I can't use keyboard shortcuts to both play a track in the preview deck using p (which is only possible when keyboard shortcuts are enabled) and then enter edit mode using the keyboard too (the F2 key is only bound to this function when keyboard shortcuts are disabled).

Proposed Solution (as implemented)

Add a keyboard-triggerable EditItem action (name is up for debate, but matches the existing GoToItem action) that can be remapped using Custom.kbd.cfg. The default keyboard mappings bind EditItem to the r key,
basically because it was the only easily-reachable key not bound yet, but due to being able to rebind it myself, I am open for other suggestions. What I considered so far:

Not providing a default mapping: Kinda bad for discoverability of the feature, but would be fine by me
Binding EditItem to Ctrl+Shift+Return: Makes sense from the viewpoint of consistency (because Ctrl+Enter is already bound to opening the track menu, and Enter is interpreted as "edit this shell" e.g. in Excel and Google Sheets.
Binding EditItem to Ctrl+e: Would work, is easily reachable, but incurs the risk of mistiming the Ctrl press and invoking loop_double (which is mapped to e) instead when editing a lot of tracks.
Binding EditItem to r: The key is easily reachable, not mapped to anything important yet, and has the mnemonic of Rename to remember it by.

Further Work

Adapt the keyboard shortcut table at mixxxdj/manual once the default key binding has been agreed upon.
Making the "Star Rating" column editable by keyboard: I'm already working on this, and have a PR nearly ready, but due to the "special" behavior of the star rating column that allows you to edit it simply by hovering over & clicking a star without focusing the cell first, care has to be taken so that the feature works as expected in all circumstances.
Open a context menu providing the option to clear the playing count when attempting to edit the playing count column.
Possibly adding a toggle option (or separate command) that keeps the "editor mode" active not only when navigating horizontally using Tab/Shift+Tab, but also when navigating vertically using the Up and Down arrow keys.

JoergAtGithub · 2024-04-21T10:45:21Z

Welcome at Mixxx!
As a first-time contributor we need you to sign the Mixxx Contributor Agreement and comment here when you have done so. It gives us permission to distribute your contribution under the GPL v2 or later license and the Apple Mac App Store. It is also helpful for us to have contact information for contributors in case we may need it in the future.

cr7pt0gr4ph7 · 2024-04-21T11:20:59Z

Welcome at Mixxx! As a first-time contributor we need you to sign the Mixxx Contributor Agreement and comment here when you have done so. It gives us permission to distribute your contribution under the GPL v2 or later license and the Apple Mac App Store. It is also helpful for us to have contact information for contributors in case we may need it in the future.

Done 👍 (signed under my real name, i.e. Lukas Waslowski)

ronso0

Thank you for working on this!

I left some notes.
Please also check the CI remarks.

ronso0 · 2024-04-22T01:29:24Z

src/widget/wtracktableview.cpp

+void WTrackTableView::editSelectedItem() {
+    if (state() != EditingState) {
+        QKeyEvent keyEvent(QEvent::Type::KeyPress, Qt::Key_F2, Qt::NoModifier);
+        edit(currentIndex(), EditKeyPressed, &keyEvent);


Why not use the simple method edit(index)?

Thank you for the suggestion. I replaced the keyEvent with nullptr in the new (rebased) version of this PR (because I ended up not needing foitr the future follow-up PR related to StarEditor). The EditKeyPressed flag on the other hand is specified for two reasons:

The edit is triggered because of the user pressing the platform edit key (resp. a replacement for that key), so it makes sense to pass that knowledge along using the API provided for this.

I need the flag in the follow-up PR to distinguish certain user-triggered invocations of edit() from those that are triggered internally by QAbstractItemView.

IIUC you don't need it for this use case. The simple implementation with just the index calls the base function with AllEditTriggers
https://github.com/qt/qtbase/blob/e7362764d4931f255d2377462df8ac7a0d4e7c84/src/widgets/itemviews/qabstractitemview.cpp#L1233-L1240
and that starts editing except the trigger is DoubleClicked or SelectedClicked.
https://github.com/qt/qtbase/blob/e7362764d4931f255d2377462df8ac7a0d4e7c84/src/widgets/itemviews/qabstractitemview.cpp#L2749

The EditKey is already enabled here btw, and IIUC that is captured in keyPressEvent and is not relevant for this new slot editSelectedItem.

mixxx/src/widget/wlibrarytableview.cpp

Line 31 in 67a41d9

setEditTriggers(QAbstractItemView::SelectedClicked|QAbstractItemView::EditKeyPressed);

Tl;dr
IMO we don't need the trigger here and I'm curious about your follow-up ; )
Do you mind sharing a link to your WIP branch?

Apart from that this PR looks good to me btw.

src/proto/httpplugin.proto

…ard shortcut The default platform edit key F2 is often already mapped to other commands when keyboard shortcuts are enabled, so we want to be able to specify a custom key instead to allow full control via keyboards.

All other simple single-key shortcuts are actually taken, and mapping the action to e.g. Ctrl+e would incur the risk of accidentally invoking the loop_double action that is mapped to "e" - especially when you are bulk-editing a lot of tracks.

… in the sidebar

cr7pt0gr4ph7 · 2024-04-24T06:30:59Z

I integrated the review suggestions and fixed the build failures (and have setup the CI pipeline on my fork, so the latter shouldn't happen anymore for future PRs). Thanks for the quick reaction!

ronso0 · 2024-04-24T10:06:08Z

src/widget/wlibrarysidebar.cpp

@@ -176,6 +176,20 @@ void WLibrarySidebar::dropEvent(QDropEvent * event) {
    }
 }

+void WLibrarySidebar::editSelectedItem() {


should better be renameItem() since that's all it does (compared to the table view where we can indeed use "edit" because we don't rename the track, just the metadata item)

isExpanded() is not a good way to check for root nodes, because it returns false for root nodes that are not currently expanded. SidebarModel::renameItem will handle root nodes appropriately anyway.

daschuer

The code looks good. I have not tested yet.
@ronso0 does that fit into our keyboard layout?
In window explorer renaming is on F2

ronso0 · 2024-04-26T08:13:17Z

Yep, we only have Ctrl+R for Recording.

The idea is to have an alternative for F2 because it's mapped to rate_temp_up.

ronso0 · 2024-04-26T08:13:39Z

Haven't tested it either, yet, will do so next week.

ronso0 · 2024-04-26T10:58:21Z

IIUC we now need to query the keyboard config via KeyboardEventFilter in order to show the correct shortcut in the sidebar context menu. I.e. show either F2 (keyboard disabled) or R/custom key (keyboard enabled).

This happens here for playlists

mixxx/src/library/trackset/baseplaylistfeature.cpp

Line 77 in 67a41d9

m_pRenamePlaylistAction->setShortcut(kRenameSidebarItemShortcutKey);

and here for crates

mixxx/src/library/trackset/crate/cratefeature.cpp

Line 71 in 67a41d9

m_pRenameCrateAction->setShortcut(kRenameSidebarItemShortcutKey);

An example is in WMainMenubar or LegacySkinParser

Updating the shortcut when toggling the keyboard is a bit more tricky.
Though, I think both is required for this PR : |

Please also check #13082 (not sure if it conflicts)

cr7pt0gr4ph7 · 2024-04-26T11:17:27Z

@ronso0 Thanks for bringing that to my attention! I'll have a look at the displaying the correct keyboard shortcuts, and will try a local merge with #13082. Based on a quick glance at the latter, this doesn't conflict with my pull request as of now, but might interact with the reload logic.

ronso0 · 2024-04-26T11:55:20Z

Just FYI #13082 hasn't been reviewed, yet, so it's unclear if it'll be merged as it is now and when that'll happen of course.
I.e. I don't recommend to make this PR depend on #13082

ronso0 · 2024-04-26T12:59:37Z

I think, with current main, we need to pass a CoreServices (or KeyboardEventFilter) pointer to the library features that need to access the keyboard cfg, and maybe update the sidebar action shortcuts as required in every call of ...Feature::onRightClickChild().

Connecting the WMainMenuBar::toggleKeyboardShortcuts(bool enabled) signal to the library features is also possible but is certainly even more work.

cr7pt0gr4ph7 · 2024-04-26T13:23:34Z

@ronso0 I've written a quick-and-dirty implementation based on your code, which I will share shortly (as soon as it has built on my machine).

I think the most clean way is to "register" the actions that have to be updated with the KeyboardEventFilter (possibly wrapped behind an abstract KeyboardShortcutManager interface). The library features already receive the KeyboardEventFilter* when LibraryFeature::bindLibraryWidget(WLibrary*, KeyboardEventFilter*) is called,so we can just register the actions with the KeyboardEventFilter then and there.

The code looks quite clean and natural this way. Additions like using a proxy to control lifetimes etc. are also easily possible, but probably not needed anyway. It should probably suffice to use QPointer<QAction> instead of QAction* for storing the references to the actions in KeyboardEventFilter, and to periodically remove actions that have been deleted.

cr7pt0gr4ph7 · 2024-04-26T13:29:03Z

@ronso0 Update: The code can be found here: cr7pt0gr4ph7/mixxx@44a12a8...efc7cd1 (branch is wip-fix-star-rating-merge)
I'll have a look on how to port this to the main branch, if it's forseeable your PR won't be merged anytime soon.

(By the way, I am building Mixxx on my Linux machine inside a VS Code DevContainer, and its sloooooooooow as soon as multiple files are affected. Do you maybe have any tips for speeding the builds up? I am still waiting on the rebuild to finish...

cr7pt0gr4ph7 · 2024-04-26T15:57:07Z

I have looked into the issue of trying to display the correct shortcuts on context menu items etc. Here's my current conclusion:

There are a lot of places in the UI where keyboard shortcuts are available/configurable (e.g. for [Library] AutoDjAddTop) but not displayed in the UI. It would probably be sensible to implement all of those places in the same way.

The implementation for this will most likely look very similar to what @ronso0 has done at Keyboard: automatically reload mapping file and update tooltips #13082. I'd be happy to help on that effort and/or provide a suitable pull request myself. (I actually have a working implementation based on that pull request, which can be found (together with some other stuff) at https://github.com/cr7pt0gr4ph7/mixxx/tree/wip-fix-star-rating-merge).
This PR doesn't really break things any further than they already are, i.e. Mixxx already displays a shortcut for "Rename" that doesn't work when keyboard shortcuts are enabled & F2 is bound to something else.
Implementing the shortcut display logic correctly & cleanly requires passing around parameters to a lot of places and would benefit from a separate discussion, while those modifications are very much orthogonal to the contents of this pull request.

I would therefore argue for keeping this PR self-contained and getting it merged, and deferring the issue of displaying the shortcuts to a separate PR.

ronso0 · 2024-04-27T17:28:13Z

Thank you, that sounds reasonable.

ronso0 · 2024-04-27T17:30:19Z

I am building Mixxx on my Linux machine inside a VS Code DevContainer, and its sloooooooooow as soon as multiple files are affected. Do you maybe have any tips for speeding the builds up?

I have no idea. I'm using Eclipse on Linux with cmake and ccache. With that only changed files (and those units including them) are rebuilt.

ronso0 · 2024-04-29T14:45:03Z

I think the most clean way is to "register" the actions that have to be updated with the KeyboardEventFilter

Yup, like it's done for the menu bar actions in #13082
And that shoudl be straigh forward since we only need to store the KeyboardEventFilter pointer passed around via bindLibraryWidget()

cr7pt0gr4ph7 · 2024-04-30T09:38:31Z

Yup, like it's done for the menu bar actions in #13082 And that shoudl be straigh forward since we only need to store the KeyboardEventFilter pointer passed around via bindLibraryWidget()

See one of my previous comments for a prototype of that 😉 A bit of care has to be taken to drop references to QAction instances that are created temporarily and then destroyed (e.g. when creating context menus) as well as on reloads, if and when we have such code. But besides that, the code is actually pretty simple, provided that #13082 is merged. I'll take a look at reviewing the latter.

…board shortcuts are disabled.

…eyboard shortcuts are disabled.

cr7pt0gr4ph7 · 2024-10-03T18:37:23Z

@ronso0 Finally got around to integrating the requested changes.

The R now works inside the WLibrarySidebar and WLibraryTableView widgets even when keyboard shortcuts are disabled.
The context menu now displays the shortcut(s) for the "Rename" item as "F2 | R" (Qt doesn't have a default format for displaying multiple keyboard shortcuts, so using | as the separator is just my best attempt).

Should be ready to merge ~~after the build has completed~~ now. Let me know if any additional changes are required.

cr7pt0gr4ph7 · 2024-10-18T08:15:48Z

@ronso0 Friendly ping :) Could you have a final look so we can get this merged? Thank you :)

cr7pt0gr4ph7 · 2024-10-31T14:44:30Z

Can I do anything to move this PR forward / get it merged? Thanks! :)

daschuer · 2025-01-31T23:50:46Z

I can confirm the issue. F2 is the edit shortcut if shortcuts are disabled. What is the reason not to use F2 for the edit feature when shortcuts are enabled?

ronso0 · 2025-02-01T00:31:13Z

Because that's mapped to "rate_perm_up" or similar for ages?

daschuer · 2025-02-01T13:53:49Z

I think the underlying issue is now the move of the expected hotkey for Edit.
Cumming form other applications it is F2. The same in Mixxx unless shortcuts are enabled.
Just noticing. If this is desired, we can merge. We can change that at any time later if it tuns out to be an issue.

daschuer · 2025-02-01T14:11:04Z

src/widget/wlibrarysidebar.cpp

+    case kRenameSidebarItemShortcutKey:              // F2
+    case kRenameSidebarItemAlternativeShortcutKey: { // R


For my understanding R is the adjustable shortcut alternative via kbd.cfg. We should not hard code it here.

Suggested change

case kRenameSidebarItemShortcutKey: // F2

case kRenameSidebarItemAlternativeShortcutKey: { // R

case kRenameSidebarItemShortcutKey: { // F2

R already works without this line in case shortcuts are enabled.

I can confirm the issue. F2 is the edit shortcut if shortcuts are disabled. What is the reason not to use F2 for the edit feature when shortcuts are enabled?

As previously discussed by you and @ronso, F1 through F8 are bound to actions relating to pitch bending/bpm changes, so an alternative was needed.

The reasoning for why r was chosen is explained in the PR description. I've been using it for a while now, and can confirm the usability turns out pretty well, especially when editing a number of tracks.

For my understanding R is the adjustable shortcut alternative via kbd.cfg. We should not hard code it here. R already works without this line in case shortcuts are enabled.

Yes, you are correct. The newly introduced adjustable keyboard shortcut defaults to R.

Hardcoding R in addition to F2 so R always works, even when keyboard shortcuts are disabled, was an explicit request by @ronso0. I can see the underlying reasoning, but don't feel strongly either way.

I don't see this request in the linked post.
At least it is wrong to maintain a hard coded R here, while it can be actually any key on users choice.
We consider the kind.cfg files a user configuration.

daschuer

Thank you. Left some comments.

daschuer · 2025-02-01T14:15:10Z

src/widget/wlibrarysidebar.cpp

+    case kRenameSidebarItemShortcutKey:              // F2
+    case kRenameSidebarItemAlternativeShortcutKey: { // R


R already works without this line in case shortcuts are enabled.

daschuer · 2025-02-01T14:18:49Z

src/library/trackset/baseplaylistfeature.cpp

+    m_pRenamePlaylistAction->setShortcuts(QList<QKeySequence>{
+            QKeySequence(kRenameSidebarItemShortcutKey),
+            QKeySequence(kRenameSidebarItemAlternativeShortcutKey)});


Suggested change

m_pRenamePlaylistAction->setShortcuts(QList<QKeySequence>{

QKeySequence(kRenameSidebarItemShortcutKey),

QKeySequence(kRenameSidebarItemAlternativeShortcutKey)});

If we want to show the short cut, we need to change it form F2 to the value which is picked in kbd.cfg.

Updated the code to display the correct shortcut in the context menu (though it does not dynamically react to toggling keyboard shortcuts on/off at runtime, as that requires the infrastructure implemented in #13082). This aligns with the current implementation e.g. in AutoDJFeature.

Displaying the shortcut in the context menu was an explicit request by @ronso0 during review. The decision to postpone dynamically updating the displayed shortcuts until a Mixxx-wide approach (i.e. #13082) is available was also made here together with @ronso0.

daschuer · 2025-02-01T14:20:55Z

src/library/trackset/crate/cratefeature.cpp

+    m_pRenameCrateAction->setShortcuts(QList<QKeySequence>{
+            QKeySequence(kRenameSidebarItemShortcutKey),
+            QKeySequence(kRenameSidebarItemAlternativeShortcutKey)});


Suggested change

m_pRenameCrateAction->setShortcuts(QList<QKeySequence>{

QKeySequence(kRenameSidebarItemShortcutKey),

QKeySequence(kRenameSidebarItemAlternativeShortcutKey)});

same here. Either show the correct value or nothing.

daschuer · 2025-02-01T14:21:41Z

src/util/defs.h

@@ -41,3 +41,4 @@ constexpr Qt::Key kHideRemoveShortcutKey = Qt::Key_Delete;
 #endif

 constexpr Qt::Key kRenameSidebarItemShortcutKey = Qt::Key_F2;
+constexpr Qt::Key kRenameSidebarItemAlternativeShortcutKey = Qt::Key_R;


Suggested change

constexpr Qt::Key kRenameSidebarItemAlternativeShortcutKey = Qt::Key_R;

This is not a constexpr it is set by kbd.cfg

See my previous response for why r was hardcoded.

…menu

daschuer · 2025-02-07T08:05:52Z

Can you squash the last commits into one?
We try to keep the commit history build-able.

daschuer · 2025-02-07T08:13:31Z

src/library/trackset/baseplaylistfeature.cpp

@@ -695,6 +695,19 @@ void BasePlaylistFeature::bindLibraryWidget(WLibrary* pLibraryWidget,
            &BasePlaylistFeature::htmlLinkClicked);
    m_pLibraryWidget = QPointer(pLibraryWidget);
    m_pLibraryWidget->registerView(m_rootViewName, pEdit);
+
+    // Update shortcuts displayed in the context menu
+    if (pKeyboard->getKeyboardConfig()->exists(ConfigKey("[Library]", "EditItem"))) {


This doers not work, because we can have the situation that there is no "Edit item" configured.

You need either to show the correct active short cuts or nothing. Showing a not working short cut is a bug IMHO

daschuer · 2025-02-07T08:16:13Z

src/widget/wlibrarysidebar.cpp

+    case kRenameSidebarItemShortcutKey:              // F2
+    case kRenameSidebarItemAlternativeShortcutKey: { // R


I don't see this request in the linked post.
At least it is wrong to maintain a hard coded R here, while it can be actually any key on users choice.
We consider the kind.cfg files a user configuration.

ronso0 · 2025-02-07T09:07:16Z

At least it is wrong to maintain a hard coded R here, while it can be actually any key on users choice.

I think it would be good to have static shortcuts, ie. at least one shortcut that works regardless (user) shortcuts being enabled.

daschuer · 2025-02-07T11:11:52Z

I can confirm that. I am also not particularly happy about the changing meaning of F2.

A straight forward solution would be to not use F2 in kbd.cfg. Then everything is consistent. F2 is anyway cumbersome for any perfomace hot key, because at least in case of Laptop Keyboard the key kan be permanently mapped to FN (Volume down) in my case.

If we want to srick with "R" which is clearly in the region of other keyboard mappings, and not a system wide key I will not oppose.
However the system schall behave consistent in case a user Remaps "R" to diffrent feature.

They may for example map F2 to "[Library], EditItem" to make it alwas work the same. In this case a static mapping to "R" in potions of the code is missleading.

cr7pt0gr4ph7 · 2025-02-07T18:19:47Z

Given that most arguments have already been made, I propose the following - provided you (@ronso0 and @daschuer) both agree:

Displaying shortcuts: Display neither F2 nor R, and defer dynamically displaying the correct shortcuts to Keyboard: automatically reload mapping file and update tooltips #13082 (which implements a wholistic approach).
EditItem = R vs. EditItem = F2:
- Only hardcode F2 to keep the current behavior for "keyboard shortcuts = off" and honor the users assumption that "normal" keys (A..Z, 0..9 etc.) by themselves don't do anything when "keyboard shortcuts = off".
- Leave F1 - F8 bound to their current functions, as some users (me included) heavily use those.
- Bind EditItem to R by default for "keyboard shortcuts = on", as it's easily reachable and, based on my personal experience, actually pretty ergnonomic to use, even when mass-editing tracks.

@daschuer

Can you squash the last commits into one?
We try to keep the commit history build-able.

Sorry about the noise... I'll clean up the commit history as soon as a decision has been made regarding the points above, as that might lead to the removal of some other commits.

ronso0 · 2025-02-07T23:30:35Z

Yup, I agree as well.

github-actions bot added library ui labels Apr 21, 2024

cr7pt0gr4ph7 changed the title ~~Usability: Add a rebindable keyboard shortcut for editing items as a replacement for F2~~ (WIP) Usability: Add a rebindable keyboard shortcut for editing items as a replacement for F2 Apr 21, 2024

ronso0 reviewed Apr 22, 2024

View reviewed changes

cr7pt0gr4ph7 force-pushed the configurable-edit-item-shortcut branch from 13393f9 to b4f4a3c Compare April 23, 2024 22:10

cr7pt0gr4ph7 added 3 commits April 24, 2024 01:09

LibraryControl: Map the EditItem shortcut to the "Rename" action when…

faf60e6

… in the sidebar

cr7pt0gr4ph7 force-pushed the configurable-edit-item-shortcut branch from b4f4a3c to faf60e6 Compare April 24, 2024 06:26

cr7pt0gr4ph7 changed the title ~~(WIP) Usability: Add a rebindable keyboard shortcut for editing items as a replacement for F2~~ Usability: Add a rebindable keyboard shortcut for editing items as a replacement for F2 Apr 24, 2024

ronso0 reviewed Apr 24, 2024

View reviewed changes

cr7pt0gr4ph7 added 2 commits April 24, 2024 12:28

WLibrarySidebar: Rename editSelectedItem to renameSelectedItem

0007e5e

WLibrarySidebar: Remove unnecessary condition in renameSelectedItem

0e3787c

isExpanded() is not a good way to check for root nodes, because it returns false for root nodes that are not currently expanded. SidebarModel::renameItem will handle root nodes appropriately anyway.

daschuer approved these changes Apr 26, 2024

View reviewed changes

github-actions bot added the stale Stale issues that haven't been updated for a long time. label Sep 25, 2024

cr7pt0gr4ph7 added 2 commits October 3, 2024 17:44

WLibrarySidebar: Make the alternative edit key "R" work even when key…

358d72c

…board shortcuts are disabled.

WLibraryTableView: Make the alternative edit key "R" work even when k…

1306068

…eyboard shortcuts are disabled.

cr7pt0gr4ph7 force-pushed the configurable-edit-item-shortcut branch from bb51a0a to 1306068 Compare October 3, 2024 15:44

ActionUtils: Display all shortcuts for the "Rename" menu item

77a2faf

ActionUtils: Avoid clazy compiler warning

500e883

github-actions bot removed the stale Stale issues that haven't been updated for a long time. label Oct 4, 2024

cr7pt0gr4ph7 requested a review from ronso0 October 4, 2024 14:22

ronso0 mentioned this pull request Oct 5, 2024

Usability/Keyboard: Make the star ratings in the tracks view editable via keyboard #13717

Open

cr7pt0gr4ph7 changed the title ~~Usability: Add a rebindable keyboard shortcut for editing items as a replacement for F2~~ Usability/Keyboard: Add a rebindable keyboard shortcut for editing items as a replacement for F2 Oct 31, 2024

daschuer reviewed Feb 1, 2025

View reviewed changes

daschuer requested changes Feb 1, 2025

View reviewed changes

cr7pt0gr4ph7 added 5 commits February 1, 2025 22:16

Display the correct shortcut for "Edit item" in the sidebar context menu

ffdfd84

Display the correct shortcut for "Rename Crate" in the Crate context …

b8739ab

…menu

Fix compiler errors in baseplaylistfeature.cpp

3d72079

Fix compiler error in cratefeature.cpp

eded524

Fix order of #includes in cratefeature.cpp

348b8b9

acolombier added this to the 2.6-beta milestone Feb 4, 2025

daschuer requested changes Feb 7, 2025

View reviewed changes

		case kRenameSidebarItemShortcutKey: // F2
		case kRenameSidebarItemAlternativeShortcutKey: { // R

	case kRenameSidebarItemShortcutKey: // F2
	case kRenameSidebarItemAlternativeShortcutKey: { // R
	case kRenameSidebarItemShortcutKey: { // F2

	m_pRenamePlaylistAction->setShortcuts(QList<QKeySequence>{
	QKeySequence(kRenameSidebarItemShortcutKey),
	QKeySequence(kRenameSidebarItemAlternativeShortcutKey)});

	m_pRenameCrateAction->setShortcuts(QList<QKeySequence>{
	QKeySequence(kRenameSidebarItemShortcutKey),
	QKeySequence(kRenameSidebarItemAlternativeShortcutKey)});

Usability/Keyboard: Add a rebindable keyboard shortcut for editing items as a replacement for F2 #13148

Are you sure you want to change the base?

Usability/Keyboard: Add a rebindable keyboard shortcut for editing items as a replacement for F2 #13148

Conversation

cr7pt0gr4ph7 commented Apr 21, 2024

Issue Statement

Use Case

Proposed Solution (as implemented)

Further Work

JoergAtGithub commented Apr 21, 2024

cr7pt0gr4ph7 commented Apr 21, 2024 • edited Loading

ronso0 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cr7pt0gr4ph7 Apr 23, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cr7pt0gr4ph7 commented Apr 24, 2024

Choose a reason for hiding this comment

daschuer left a comment

Choose a reason for hiding this comment

ronso0 commented Apr 26, 2024

ronso0 commented Apr 26, 2024

ronso0 commented Apr 26, 2024

cr7pt0gr4ph7 commented Apr 26, 2024

ronso0 commented Apr 26, 2024

ronso0 commented Apr 26, 2024

cr7pt0gr4ph7 commented Apr 26, 2024

cr7pt0gr4ph7 commented Apr 26, 2024 • edited Loading

cr7pt0gr4ph7 commented Apr 26, 2024 • edited Loading

ronso0 commented Apr 27, 2024

ronso0 commented Apr 27, 2024

ronso0 commented Apr 29, 2024 • edited Loading

cr7pt0gr4ph7 commented Apr 30, 2024

cr7pt0gr4ph7 commented Oct 3, 2024 • edited Loading

cr7pt0gr4ph7 commented Oct 18, 2024

cr7pt0gr4ph7 commented Oct 31, 2024

daschuer commented Jan 31, 2025

ronso0 commented Feb 1, 2025

daschuer commented Feb 1, 2025

daschuer Feb 1, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

daschuer left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cr7pt0gr4ph7 Feb 1, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

daschuer commented Feb 7, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ronso0 commented Feb 7, 2025

daschuer commented Feb 7, 2025

cr7pt0gr4ph7 commented Feb 7, 2025

ronso0 commented Feb 7, 2025

cr7pt0gr4ph7 commented Apr 21, 2024 •

edited

Loading

cr7pt0gr4ph7 Apr 23, 2024 •

edited

Loading

cr7pt0gr4ph7 commented Apr 26, 2024 •

edited

Loading

cr7pt0gr4ph7 commented Apr 26, 2024 •

edited

Loading

ronso0 commented Apr 29, 2024 •

edited

Loading

cr7pt0gr4ph7 commented Oct 3, 2024 •

edited

Loading

daschuer Feb 1, 2025 •

edited

Loading

cr7pt0gr4ph7 Feb 1, 2025 •

edited

Loading