-
-
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
Remove some skin internals from DlgPrefInterface #3891
Conversation
Please ignore the code style issues, I used |
3ba5bb4
to
dbb5f21
Compare
c310c71
to
f367b37
Compare
61e0ece
to
a1f378d
Compare
Is this the first PR that should be merged before introducing the QML skin components? |
Should I open a separate PR for the first commit to make this easier to review? |
Yes. |
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.
No objections.
class LegacySkin : public mixxx::skin::Skin { | ||
public: | ||
LegacySkin() = default; | ||
LegacySkin(const QFileInfo& path); |
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.
- ctor: explicit
- dtor: Add an
override = default
destructor
We should keep the skin related changes in 2.3.x to a minimum or shortly release 2.4.0 afterwards to avoid merge conflicts. Preventing merge conflicts is a valid reason for releasing a new version. Even if those features are not yet visible for users. |
I mean I could even rebase the renaming commit on 2.3 and open a separate PR for that. That also makes this PR easier to review. |
No, this is mainly reorganization. If it works everything is fine. |
Oops, I didn't see that comment and opend #3912. Should I close it or do we want to merge the mass renaming into 2.3 to avoid conflicts? |
Merging to 2.3 sounds reasonable. |
a1f378d
to
b94d0ee
Compare
I rebased on latest main. Ready to review/merge. I'll rebase the follow-up PRs tomorrow. |
By the way, this also fixes the situation when you configured a custom skin which is broken. Now it automatically falls back to the default skin. Before, it only used the fallback if the configured skin is missing, not when it's broken. |
This has already been approved. Merge? |
LGTM |
Unfortunately it segfaults when the skin folder is missing, after the error dialog: [New Thread 0x7fff3f2fd700 (LWP 11181)] Thread 1 "mixxx" received signal SIGSEGV, Segmentation fault. |
It segfaults at the same place when the configured skin is missing:
|
During shutdown I get this warning:
|
During start of LateNight I see various debug assertions:
|
The fall back to the default skin works. |
I'll have a look tomorrow. In this case the configured skin is the default skin, so there is no way that Mixxx is able to start anyway. |
I see this all the time, even in 2.3 beta. It's always been like that IIRC. |
Unrelated. This is a known issue on main with a fresh profile that has already been reported. |
First step to untangle our Skin system a bit, so that we can have both legacy XML skins and QML skins at the same time.
This adds a new
Skin
class that we can later make multiple subclasses from. For now, this class is only used to simplifyDlgPrefInterface
.Prerequisite for my QML skin PRs.