Unable to move library cursor from a controller when the Mixxx window loses the focus

[acolombier]

Bug Description

Summary

When the Mixxx window loses focus, it is impossible to control the selected item in the library from a controller

Actual behavior

Nothing happens when trigger control from the [Library] section (e.g: MoveVertical, focused_widget)

Expected behavior

It should still be possible to inetract with the currently focus widget and change the selected item using [Library] controls

How to reproduce

• Map a library focus action on a controller. Example: [Library] MoveVertical 1
• Ensure it works while Mixxx window has focus
• Focus an other window
• Try the mapped control again

Initial exploration

It looks like the problem could come from the file src/library/librarycontrol.cpp. My understanding is that the control focus is closely linked with the UI widget focus. The action of moving the cursor seems to emulate a keyboard input, which only works while the window has the focus.

I'm happy to explore this further or try to fix it, if you guys have an idea on how I could do that with a minimal disruption.

Version

2.4.0~alpha2~1403~gcce89d09f3-1~jammy from Nightlies PPA, tested on main too

OS

PopOS 22.04

[ronso0]

Yes, the Move... controls are supposed to be universal, i.e. they can be used in any widget that has keyboard focus incl. dialogs.
So if no Mixxx window is focused these controls are not applicable. That's what the dedicated widget controls are for, e.g. the [Playlist] controls and (in Mixxx 2.4) the searchbox controls

which only works while the window has the focus

No, unfoused widgets can also receive keystrokes, for example run Mixxx from the command line with --deveoper and set a value for [Playlist], SelectPlaylist in the Developer Tools window (Ctrl+Shift+t).

However, IIRC it has already been discussed how to make the Move... controls work while no Mixxx window has focus. It's questionable whether this is worth the effort implementing this for the legacy skins instead of working on the new QML skin system. Though, if it's doable without too many hacks, that could IMHO be the last UI tweak before switching to QML.

FWIW this is how I imagine this to work:

1. introduce a new qproperty pseudo-focus for WTracksTableView, WLibrarySidbar and WSearchLineEdit
2. note which (if any) of the library widgets is focused when the Mixxx main window loses focus
3. track/switch the 'active' widget that will receive keypress events
4. use pseudo-focus to decorate the 'active' widget
5. switch back to actual focus property as soon as the main window gets focused again.

IMO 3. is the tricky/cumbersome part.

[acolombier]

Thanks for this explanation. I didn't know there will be a change in behavior between the deprecated and new controls. My understanding is that QML is progressing well, so perhaps this bug/regression can be corrected within the new skin system only?

Following your advice, I have managed to make a workaround using the [Library] focus_widget, which perhaps can help allowing this issue to remain, till fully fixed in the new system.

Here is the full snippet in case it can help someone else:

// To move up & down cursor in playlist or side bar (sidebar if shift is true in this example)
const currentlyFocusWidget = engine.getValue("[Library]", "focused_widget");
if (currentlyFocusWidget === 0){
    if (this.shifted){
        script.triggerControl("[Playlist]", right ? "SelectNextPlaylist" : "SelectPrevPlaylist");
    } else {
        script.triggerControl("[Playlist]", right ? "SelectNextTrack" : "SelectPrevTrack");
    }
} else {
    engine.setValue("[Library]", "focused_widget", this.shifted ? 2 : 3);
    engine.setValue("[Library]", "MoveVertical", right ? 1 : -1);
}

// To load a track or expand an item (expand if shift is true in this example)
const currentlyFocusWidget = engine.getValue("[Library]", "focused_widget");
// 3 == Tracks table or root views of library features
if (this.shifted && currentlyFocusWidget === 0){
    script.triggerControl("[Playlist]", "ToggleSelectedSidebarItem");
} else if (currentlyFocusWidget === 3 || currentlyFocusWidget === 0){
    script.triggerControl(this.group, "LoadSelectedTrack");
} else {
    script.triggerControl("[Library]", "GoToItem");
}

[neopostmodern]

I just ran into this myself and want to ask what the plan is moving forward concerning [Playlist]-SelectNextTrack et cetera – it's marked as deprecated, yet it's the only way to navigate without window focus. Can I depend on it until a suitable replacement has been implemented?

[ronso0]

Yes, I think so. I'm not aware of plans to remove those controls.

[Popaulol]

Is there any way to get my FLX4 library encoder quickly working as expected when mixxx isn't focused without changing it's current control scheme? (I wouldn't mind patching and recompiling mixxx for this)

I use mixxx ans a flx4 for entry/exit and break music in a theatre context and the same machine is running a few other tasks as well on separate screens with keyboard and mouse controls.
The flx4 is about 4 meters away from the other computer controlls (there is a mixing desk and lighting control equipment in between).
So it's very annoying that I have to run back to the keyboard if I forgot to focus mixxx before walking to the controller.