Controller - library browsing input on non-focused Mixxx window

Hello everyone!

I’m using a single Windows 10 computer to run Mixxx v2.3 alongside QLC+, on a multi-monitor setup. Mixxx appears on one monitor, QLC+ appears on the other.

When the Mixxx window doesn’t have focus, such as when I’m adjusting QLC+, I cannot browse the library with the controls on my Pioneer DDJ-SX3. It works fine when Mixxx has focus.

However, the other controls work fine, so I can continue mixing, scratching, filtering, etc. I can also create an instant double of the currently playing track. So the issue is restricted to only the library functions.

Does anyone have an idea what’s going on?

IIUC the library navigation controls are implemented using simulated keyboard events which is why they don’t work when the Mixxx window is not focused. @ronso knows more here.

there’s not much to know about:
Library,Scroll… and Library,Move… commands are universal, they send Up/Down key events to the currently focused widget, which can be a beat spinbox, tracks table, sidebar, searchbox.
But without Mixxy being focused there’s no focused widget either.
If you work with multiple windows you’d need to use the [Playlist] commands which target specific widgets.

Thank you for responding.

I see that many of the [Playlist] commands are deprecated. I also see that there has been talk of changing some of this, like moving things to [Library], and creating a FocusPane command.

I imagine once I make my script use these widget commands, sometime in the (undetermined) future, I may have to make some changes.

I’m working on updating my script right now.

Thank you for the help.

Unfortunately it seems like there is insufficient controls to be able to do what I want.

I can move the Playlist selector up and down, and expand/collapse branches with the Mixxx window focused and unfocused. - GREAT!

Once I’m on the last child entry in a particular branch (eg: Crates->Psytrance), I cannot make it jump over to the track window to select a track by short-pressing the rotary selector. It doesn’t matter if the Mixxx window is focused or not.

Is there a way to detect when the selector is on the last child entry? If there is a way to do that, then I can use a short press.

The work-around I’m considering for now is creating a rotary selector long-press event to switch to the playlist. It’s not my preference, but it will do the job.

Any advice is greatly appreciated.

Edit: After messing around, I realized it isn’t going to work very well, very poor work-around. Scrap that idea. Still looking for a solution.

The [Playlist] controls exist side by side, i.e. there is no such thing as jumping. You need to track the sidebar/table state in the script, like: every rotary longpress switches between SelectPlaylist and SelectTrackKnob.
Or use (pressed+turn) for the sidebar, and turn for the tracks.

The solution for simple “un-focused controller interaction” would be to create an Mixxx-internal equivalent for the widget focus, and pass that around between searchbox, sidebar and tracks table. (Mixxx 2.4 will save search queries per session and thus accept Up/Down commands, too)
Questionable if someone will tackle this given the fact that the basis for a new skinning system with QML is already being built.

Hi Ronso, thank you for responding.

I have already attempted to track the states of the sidebar/table. I was successful in being able to independently control the sidebar and the track list using only the rotary selector.

The main issue I encountered is when you accidentally long-press on the rotary selector to switch to the other frame; if you do that on a branch that contains no tracks (eg: Top->Crates), it caused an issue.

Another issue is if someone were to click on a different pane, the script would become out-of-sync.

For some reason as well, my code got screwed up when trying to implement the long-press, and now I have to double-click the rotary selector to traverse branches, so I’ll have to look at that. LOL.

I agree with your solution, creating Mixxx-internal equivalents, and understand that’s probably not going to happen. I guess what I don’t understand from your response is when the new QML skinning system is created, whether this functionality might become part of that. The feeling I’m getting is that no one will do it for v2.3, or future versions until the new skinning system is done, and then maybe; feel free to correct me.

I’m considering preparing my system to compile Mixxx v2.3, and learning how to add the functionality, using the existing functionality as an example. Maybe this could help/be ported forward for future versions. When I consider the advantages and disadvantages of doing it either way (keyboard equivalent vs. the way that works for my use case), I believe that the keyboard equivalent could be problematic for Windows users if a window pops up and steals focus in the middle of a set. Could be beneficial. It could be my contribution, as small as it is.

Is there anything I need to know about Mixxx’s contribution policies before I give it a try?

At this point there are no specific plans for the design of the library GUI with QML. We’ll try to keep the old library navigation controls working but it’s hard to say if/how that will be possible before knowing what the GUI will look like.

Understood, thank you for letting me know.

Yeah, I’m pretty interested in adding in the support I need for my personal install of Mixxx v2.3, and maybe I can help with adding the capabilities to v2.4 as the new GUI is finalized, if you would like me to.


Great, give it a shot!

This is what I had in mind:

  • mimic the focus property of QWidgets with a custom qproperty pseudoFocus added to WTracksTable, WLibrarySidebar and WSearchLineEdit only
    = in skin stylesheets set a pseudoFocus border (in a different color than the regular focus border)
  • when those widgets are created add them to a list (i.e. focusableLibraryWidgets) which can somehow be accessed by librarycontrol.cpp
  • make MixxxMainWindow track the regular focus state by overriding focusInEvent() / focusOutEvent(): check which of the library widgets is currently focused (or none) and set its pseudoFocus to true (somehow guarantee that only one of those pseudoFocus-able widgets has focus – set all to false when the regular window focus takes over
  • [Library],MoveFocus.. controls need to check wether the Mixxx window has focus (send Tab events) – or not (cycle through focusableLibraryWidgets)
  • make [Library],Move../ Scroll../ MoveFocus.. and [Playlist],Select... controls deal with both focus and pseudoFocus : p and send QKeyEvents to the respective widget

Good luck!

(as soon as you are starting to work on it open PR to discuss the implementation as soon as possible)