remove WTrackText class, use WTrackProperty or WLabel

[ronso0]

reduce code duplication / maintenance

Update
First, I made WTrackText inherit from WTrackProperty (diff was only the setup()), then realized that the Text widget was actually a WLabel with a fixed text and the ability to read a Group to show 'track info' #12004 (comment)

Now, WTrackText is removed entirely. When parsing a Text widget node LegacySkinParser decides right away whether to construct a WLabel or a WTrackProperty:

• if a Group is defined (or Channel, legacy) use WTrackProperty (ignore Text node)
  • invalid group: empty
  • valid group:
    • Property defined: show that (empty if property is invalid)
    • no Property node: show track info
• if Text is defined simply use WLabel

Outcome:
Both Text and TrackProperty work as before, just without the code duplication of WTrackText.

[Swiftb0y]

as rightfully pointed out by clazy.

Suggested change

	WLabel::setup(node, context);
	WTrackProperty::setup(node, context);

[ronso0]

nope, false positive: we do exactly not want that setup which parses the widget context for Property node since WTrackText is explicitly trackInfo not some specific tag.

[ronso0]

How can we let clazy know about it?

[Swiftb0y]

See https://github.com/KDE/clazy/blob/master/README.md#reducing-warning-noise
Feel free to reformulate the comment.

Suggested change

	WLabel::setup(node, context);
	// we do exactly not want that setup which parses the widget context
	// for Property node since WTrackText is explicitly trackInfo not some specific tag.
	WLabel::setup(node, context); // clazy:exclude=skipped-base-method

[ronso0]

Thanks! Was on mobile so looking this up was rather cumbersome.
Fixed.

[ronso0]

I understand. In that case the base class would handle track loading, dnd & context menu events, and it would be of no practical use (no text is displayed, much like WTrackWidgetGroup).
The derived classes would only need to define setup, updateLabel and mouseDoubleClickEvent.

Actually, with this PR, we could deprecate WTrackText (just migrate to WTrackProperty in the official skins) and the outcome would be the same, though I didn't consider that since in the first place because WTrackText is probably used in custom skins.

If I would have thought of that, I'd also had been obvious that we can drop WTrackText and use WTrackProperty with just a few changes in legacyskinloader 🤦‍♂️
See last commit.

[ronso0]

No, that would have been too easy.
WtrackText is just the Text widget and it's designed for two scenarios:

• if there's a Text defined that string is displayed (basically the same as WLabel)
• if there's a Group defined it shows "track info" (artist &/ title / file name) (and ignores Text, if defined)

I think my proposal from above can be implemented in legacyskinparser:

• if a Group (or Channel, legacy) is defined use WTrackProperty (ignore Text node)
  • invalid group: empty
  • valid group:
    • Property defined: show that (empty if property is invalid)
    • no Property node: show track info
• if Text is defined simply use WLabel

Outcome:
WTrackProperty + WLabel, drop WTrackText class

I'll take a look. If the changes are too cumbersome I propose to merge this PR as a first step.

[Swiftb0y]

Sure... I don't understand all of what you're saying because I'm not familiar enough with the skin system so I can't really form a well informed opinion.
This PR doesn't worsen the code in anyway, so sure we can merge now and do the rest later.

[ronso0]

Ha, done!

Test for skin regression without the skin migration commit f29580c

[ronso0]

Testing without f29580c:

• all knob labels and fixed deck labels should be okay
• the only place where Text was used from 'track info' are all preview decks and samplers Shade

[ronso0]

I updated the PR description.
Let me know if you think we need more comments or skin warnings to point out the migration (I doubt it).

[ronso0]

I'm not sufficiently familiar with QMetaProperty, I need some help with moving the the property checks to setup, i.e. remove
https://github.com/mixxxdj/mixxx/pull/12004/files#diff-013766ebc9381f99ed2ced22f2dc4d51f48f143ab8f4a251a065304b0599e8a5R99-R101
and do all checks here
https://github.com/mixxxdj/mixxx/pull/12004/files#diff-013766ebc9381f99ed2ced22f2dc4d51f48f143ab8f4a251a065304b0599e8a5R59
Is this feasible? Is it recommended, or should we simply leave as it is?

[daschuer]

Yes it should be possible. Take a look here:
https://github.com/qt/qtbase/blob/94df3f8d6bfb40c9339256a93e47a495caff152c/src/corelib/kernel/qobject.cpp#L4249

Not sure if everything is accessible though but the code in may store the ID WTrackProperty::setup() and than use it in WTrackProperty::updateLabel via (Untested) :

const auto *pMetaObject = m_pCurrentTrack->metaObject();
if (pMetaObject) {
    QVariant propertyValue =  pMetaObject->property(m_propertyId).read(m_pCurrentTrack); 
}

[daschuer]

The code looks and works good, by the way. Just give a hint when I should press merge.

[ronso0]

Thanks. I'm (briefly) looking into the property topic right now. Either I find a solution with your hints in the next hour, or not.

[ronso0]

I'll give up regarding consolidating the property checks. What I had in mind was doing the QVariant::isvalid and QVariant::canConvert<QString> checks in the setup, not every time the label is updated. Though, canConvert is not static and I didn't figure a quick way to do the check without too much hazzle. If anyone wants to try it, go ahead.

Ready to be merged.
Thanks for your reviews!

[ronso0]

Btw I'd squash the first two commits if you agree.

[daschuer]

Yes, go ahead.

[ronso0]

Done, ready for merge.

[daschuer]

Thank you.

[ronso0]

Oh, I forgot to remove the now unused files.
I did so now, and also merged 2.4 into main.