keyboard navigation appears broken in crate section of track context menu

[mixxxbot]

Reported by: daschuer
Date: 2017-12-26T23:32:36Z
Status: Confirmed
Importance: Medium
Launchpad Issue: lp1740193

---

Keyboard navigation is broken in crate section of track context menu
Now that we have check boxes in the crate menu, you cannot move the focus around as expected using keyboard.

[mixxxbot]

Commented by: essence-82
Date: 2017-12-28T09:47:01Z

---

Testing the latest version of mixxx x64 2.01 alfa this problem still remains.

[mixxxbot]

Commented by: Be-ing
Date: 2017-12-28T14:12:25Z

---

Hi Ray, we have not started working on this yet. We will change the status of this bug to In Progress when we have. I understand this is a big usability issue so this is definitely on our radar to fix soon.

[mixxxbot]

Commented by: Be-ing
Date: 2018-01-08T05:11:19Z

---

Probably caused by #1341 or #1427

[mixxxbot]

Commented by: ntmusic-deactivatedaccount
Date: 2018-01-13T06:05:11Z

---

Replacing the nested QCheckBox/QWidgetAction with pAction->setCheckable(true); in WTrackTableView::slotPopulateCrateMenu() seems to fix the keyboard navigation. 

[mixxxbot]

Commented by: poelzi
Date: 2018-01-22T04:51:08Z

---

I tried to replicate the bug, but for me the menu behaves like it should. The checkable solution I tried first, but it does not allow the tristate option which is required for correct behavior.

Maybe it depends on OS ? Works fine on Linux with KDE Desktop.

[mixxxbot]

Commented by: davidhm
Date: 2018-03-18T22:38:32Z

---

So, here's the things I've tried:

• Subclassing QCheckBox and reimplementing the keyPressEvent() to catch the enter key. Doesn’t work, apparently the key event doesn’t get through the QWidgetAction class.

• Subclassing QWidgetAction and reimplementing the event() function. Doesn’t work either.

• Connecting the QWidgetAction triggered() signal to the inherited toggle() slot from QCheckBox. It works partially, but not as intended. When connecting all actions to their respective checkboxes and pressing enter on whichever crate, only the last crate is modified. I will investigate further.

Also, I don't know if this can be done but ideally pressing enter would only select or unselect the crate, not pop the menu. However, the latter happens because it's the default behaviour for QMenu when an action is triggered. As mentioned in point 2, I tried reimplementing the event() function in the QWidgetAction but it doesn't work.

[mixxxbot]

Commented by: Be-ing
Date: 2018-03-22T13:10:33Z

---

I think you may have been working with the wrong widgets, David. Perhaps intercepting arrow key up/down events from the m_pCrateMenu and using QMenu::setActiveAction could work.

[mixxxbot]

Commented by: Be-ing
Date: 2018-03-22T16:12:53Z

---

I just tested this again and it actually does work, just not quite as expected. The active crate is indicated by a dotted border around the name and crates can be selected/unselected with the space bar. This is unexpected because the background color of the item in the menu does not change when it is selected. I will see if I can fix that.

[mixxxbot]

Commented by: Be-ing
Date: 2018-03-22T16:14:58Z

---

When the Crates menu is first shown, no item is highlighted so it seems like navigating with the arrow keys would not work. However, pressing the up and down arrows does actually work.

[mixxxbot]

Commented by: ronso0
Date: 2020-10-22T16:29:57Z

---

Is this fixed with recent stylesheets for all menus on Windows, too?