QML: Library Improvements

[Holzhaus]

Currently unfinisehd because the developer tools are missing in the QML skin since #4327.

[ywwg]

do you want to revert that change, or would it be better to try to re-add the developer tools separately? My understanding is that because of the qt6 change, QML is our top priority right now, so it seems like making it easy to develop for QML is important. I haven't been following the qml work closely so I don't know how big a deal it would be to re-add developer tools

[Holzhaus]

If you want to try this out: The MoveVertical/SelectTrackKnob/LoadSelectedTrack COs already work, which makes the QML TrackList usable from a controller. To make this possible, I reimplemented LibraryControl in pure QML. Please let me know if you have any comments regarding the implementation, unsure if this is the best way.

[Swiftb0y]

Please rebase to eliminate conflicts because of #4582

[ronso0]

Do you intend to 'duplicate' librarycontrol so that it's not only responsible of the tracks table but also of managing controls/signals for the sidebar, feature bar and search bar?

Reason I'm asking is I have a WIP branch where I'm moving stuff out of LibraryControl::emitKeyEvent into the respective slots connected to the controls like GoToItem, MoveVertical etc. by making use of the FocusWidget enum. All that with QML and future multi-pane library design in mind which can re-use FocusWidget to some degree (don't want to make the transition to QML more complicated but hopefully easier).

[Holzhaus]

Do you intend to 'duplicate' librarycontrol so that it's not only responsible of the tracks table but also of managing controls/signals for the sidebar, feature bar and search bar?

Reason I'm asking is I have a WIP branch where I'm moving stuff out of LibraryControl::emitKeyEvent into the respective slots connected to the controls like GoToItem, MoveVertical etc. by making use of the FocusWidget enum. All that with QML and future multi-pane library design in mind which can re-use FocusWidget to some degree (don't want to make the transition to QML more complicated but hopefully easier).

Well, ideally the LibraryControl c++ would be independent of QWidgets and not invoke any methods on widgets at all. Instead it could just emit signals that the Library widget, the sidebar widget, etc. connect to. Then we wouldn't need the qml LibraryControl implementation at all.

[ronso0]

So librarycontrol will also be unaware of 'widget' focus and always fire signals to all connected components?

[Holzhaus]

So librarycontrol will also be unaware of 'widget' focus and always fire signals to all connected components?

Not necessarily. It should be possible to check the focused_widget CO value and take that into account. But there aren't that many widgets anyway, right?

[ronso0]

But there aren't that many widgets anyway, right?

Not yet ;) I was just thinking of the library redesign, and that there will probably 2+ sets of [tracks, side/feature bar, list view and searchbar], and to me it feels more effective making librarycontrol the switch for library controls (where all present library widgets are registered when the skin is parsed), instead of letting all widgets deal with the signals independently depending on widget focus
Furthermore I still like to make all library controls work without requiring the Mixxx window having focus but with an alternative pseudo-focus property (see lp:1771611)
So my questions are simply ment to remind of that and that we consider it while setting the new library base in QML.

[Holzhaus]

I had to rebase on #4616 because for some reason CI complained about MathUtils.mjs.

[Swiftb0y]

A QtObject does not have an enabled property. Receiving keyboard and mouse events is a QtQuick feature and thus managed through the QtQuick qml base type Item. This is probably why the QtObject version breaks. Maybe because its breaking on evaluating !undefined since root.enabled is undefined?

[Swiftb0y]

Also if removing the Item dependency still didn't fix it, maybe we're using QtObject wrong and the base should be a Component instead?

[Holzhaus]

Item doesn't have an enabled property either, I was declared here. And in any case, it should throw a warning, not cause a segfault. Component doesn't work either, same issue as with QtObject.

[Swiftb0y]

It was declared here

Sorry, I missed that, still Item does have an enabled property. I guess the declared one shadows the Items one. https://doc.qt.io/qt-5/qml-qtquick-item.html#enabled-prop

And in any case, it should throw a warning, not cause a segfault.

Yes, of course. The crash is still a bug, though I thought I might have found the issue thats triggering the bug and we could work around it, but I was wrong.

[Holzhaus]

Merge?

[Swiftb0y]

Currently does not work at all with touchscreens so we should address that soon. Other than that, LGTM

[Holzhaus]

Currently does not work at all with touchscreens so we should address that soon. Other than that, LGTM

I don't have a Touchscreen, but clicking on a row should work?

[Swiftb0y]

Yes that does work, but the library is not flickable as you would expect from a touch-enabled UI