-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
avoid issue with stars_up/_down
ControlObjects
#12591
Conversation
843f74e
to
e6e400f
Compare
stars_up/_down
issuestars_up/_down
ControlObjects
…skin reload If owned by WStarRating, and controls have actually been used, and the skin is destroyed, it seems that only the ControlObjects are destroyed but not the underlying ControlDoublePrivates.
e6e400f
to
8395db2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good. What is the reason not always set up the stars_up/down controls in the BaseTrackPlayerImpl() constructor? This way it is always available for controllers and keyboards.
You mean for all players, not just decks? |
That was my first idea actually but I am unsure. We can move alternative to the Deck() constructor. The other aspect is, that we normally instantiate the COs without GUI. Here the skin takes control which creates a asymmetry compared to the "track_color" CO for instance. |
Verifying the track color is easier. So, yeah, the controls could be created unconditionally but for that to be useful some of the rating logic has to moved to BaseTrackPlayer. Tbh I'm not really up to that right now, but I'll definitey look into it after this was merged. |
Ah OK that the issue, the star logic is anyway in the widget. Yes we need to change that on the long run to be prepared for QML. |
Okay, thanks for reviewing. |
I took a look and it was less work than expected. #12648 |
Supposed to fix
one half of#12560Moved the COs from
WStarRating
toBaseTrackPlayerImpl
, and the skin parser now connects this extra signal.The reason for #12560 is not clear to me, but this is safer because the only responsibility of the widgets is now to listen to change request signals.
The first commit is picked from #12582
edit @Swiftb0y mentioned a potential cause https://mixxx.zulipchat.com/#narrow/stream/109171-development/topic/help.20with.20unique_ptr.20.2F.20ControlObjects.20not.20being.20destroyed