Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

remove WTrackText class, use WTrackProperty or WLabel #12004

Merged
merged 2 commits into from
Dec 27, 2023

Conversation

ronso0
Copy link
Member

@ronso0 ronso0 commented Sep 20, 2023

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.

@github-actions github-actions bot added the ui label Sep 20, 2023
@ronso0 ronso0 force-pushed the wtracktext-subclass branch from f5a5f2b to dec47ea Compare September 20, 2023 08:41
@ronso0 ronso0 marked this pull request as draft September 20, 2023 10:02
@ronso0 ronso0 force-pushed the wtracktext-subclass branch from dec47ea to a68fb79 Compare September 20, 2023 10:08
@ronso0 ronso0 marked this pull request as ready for review September 20, 2023 10:08
src/widget/wtracktext.cpp Outdated Show resolved Hide resolved
m_pTrackMenu->popup(event->globalPos());
}
void WTrackText::setup(const QDomNode& node, const SkinContext& context) {
WLabel::setup(node, context);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as rightfully pointed out by clazy.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How can we let clazy know about it?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

@ronso0 ronso0 Sep 28, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ha, done!

Test for skin regression without the skin migration commit f29580c

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 ronso0 force-pushed the wtracktext-subclass branch from a68fb79 to ceb7754 Compare September 21, 2023 07:56
src/widget/wtracktext.h Outdated Show resolved Hide resolved
@ronso0 ronso0 force-pushed the wtracktext-subclass branch from ceb7754 to d1ba96d Compare September 21, 2023 09:19
@ronso0 ronso0 changed the title make WTracktext a WTrackProperty subclass remove WTrackText class, use WTrackProperty or WLabel Sep 28, 2023
@ronso0 ronso0 requested a review from daschuer September 28, 2023 23:26
@ronso0
Copy link
Member Author

ronso0 commented Sep 29, 2023

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
Copy link
Member Author

ronso0 commented Sep 29, 2023

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
Copy link
Member

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); 
}

Copy link
Member

@daschuer daschuer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@ronso0
Copy link
Member Author

ronso0 commented Sep 29, 2023

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
Copy link
Member Author

ronso0 commented Sep 29, 2023

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
Copy link
Member Author

ronso0 commented Sep 29, 2023

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

@daschuer
Copy link
Member

Yes, go ahead.

@ronso0 ronso0 force-pushed the wtracktext-subclass branch from 53413b6 to c18e41f Compare September 30, 2023 12:52
@ronso0
Copy link
Member Author

ronso0 commented Oct 24, 2023

Done, ready for merge.

@ronso0 ronso0 force-pushed the wtracktext-subclass branch from c18e41f to e3e547b Compare December 25, 2023 14:39
@daschuer
Copy link
Member

Thank you.

@daschuer daschuer merged commit d96d929 into mixxxdj:2.4 Dec 27, 2023
13 checks passed
@ronso0 ronso0 deleted the wtracktext-subclass branch December 27, 2023 12:44
@ronso0
Copy link
Member Author

ronso0 commented Dec 27, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants