-
-
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
(POC) add skin styles for Preferences & Track Properties, LateNight PaleMoon only #13842
base: main
Are you sure you want to change the base?
Conversation
129b65a
to
68bf3cd
Compare
After doing some live tests I decided to style ALL dialogs. |
Is it an option to get a day/night switch in the preferences in the future? |
A daylight color scheme would do the trick. |
0c62db5
to
9320132
Compare
9320132
to
a803962
Compare
02d4329
to
171a170
Compare
Alright, I'm now happy with this. Looks like it's easy to keep the preferences theme intact for skins/color themes other than LateNigh PaleMoon, will finish this. Also, I was wrong about the slowdown: skin re/load is as fast as before (besides those extra ~200 ms for styling the preferences, of course). |
Let me know if there's interest in polishing this for getting it in main. |
YES! |
…teNight PaleMoon only * use skin stylesheet for preferences * use skin stylesheet for all dialogs spawned by non-GUI classes by using MixxxMainWindow's centralWidget() (#Skin) as parent, via mixxx::widgetHelper
171a170
to
6216c8b
Compare
smaller stylesheets are applied faster, preceding QRegExp/string operations is super fast
6216c8b
to
0757582
Compare
Yeah I'm sure there are users who appreciate this, though my question was rather whether core devs a) see a necessity for this and b) are okay with the c++ hacks. (and I myself am not 100% convinced that this is appropriate for the official version) |
a) b) Is there much work left? If you ask me what else is important regarding skins:
|
Thanks for your feedback! I'm aware of the other helpful tweaks (just commented in #13854, not possible in the QWidget skins, and I might take a stab at the (LateNight) daylight theme during winter).
Great!
Yes. Keeping the other skins/themes intact is a hazzle because of how style sheets are inherited. In particular QTooltips and WColorPicker's bg & button style in Track Properties.
I don't expect trouble with that because, except for some |
One of my infamous 'coffee break projects'
Reason is that I don't have / can't built Qt6ct to get a proper dark theme, yet, ie. I get the rather bright default Qt theme which is annoying when playing in dark places.
So I styled Track Properties and the preferences manually. PaleMoon only!
Still WIP but is already usable and a huge improvement for me.
Update:
After doing some live tests I decided to style ALL dialogs.
This required some not-so-nice fixes / hacks in c++, see (A). If someone has ideas for alternative solutions feel free to post them.
Disclaimer:
QGroupBox
selector that will not anymore be transformed toWWidgetGroup
. I could add a warning so this change can be noticed by users but this has no prio at all.(screenshots are a bit outdated but you get the idea..)
(A) The most important "fix" is to use the main "Skin" widget as parent for all dialogs created by non-GUI classes, accomplished with a widgethelper function that finds the centralWifget() "Skin" amongst the QApplication::topLevelWindgets().
While it works it introduces the tiny risk that the Skin widget is being destroyed / recreated while a dialog is open. This is rather unlikely (who would reload a skin while something like Track Export is active?) and would only kill such dialogs.
Alternative (neither evaluated nor tested):
use the mainwindow as parent, catch 'ChildAdded' events, add the centralWidget()'s stylesheet to new children.