-
-
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
Hotcue RGB colors #2520
Hotcue RGB colors #2520
Conversation
9f3a4db
to
ebbab57
Compare
By the way, should the Palette Editor and Mass Migration stuff go into a separate PR? I think that this PR is already big enough right now... |
b73ca8f
to
c10590b
Compare
TODO (pass-by-value): Replace all occurrences of |
Actually we didn't really talk about palette editor/hotcue auto assign stuff that much. #2530 hasn't been reviewed yet. We talked about this a bit in December, but that's it: https://mixxx.zulipchat.com/#narrow/stream/109171-development/topic/color.20palettes |
I am just in progress to create a WHotcueButton, that has a context menu and handles the color connection implicit. |
Shall we merge this now and and do the hotcue button as a separate PR or do you want to file the PR against my repo and get it merged it into this branch first? |
From what I understand there'll be quite a few skin changes required to implement WHotcueButton. |
L G T M thank you! |
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.
Just some minor comments. As soon as the DB migration is finalized we should merge this PR. Bugfixes and tuning could be done later.
Due to the size of this PR (not your fault) any new review is time consuming. Following every single, new commit is impractical. As long as we don't introduce serious regressions I'm (almost) fine with the current state.
src/preferences/configobject.h
Outdated
@@ -187,6 +187,8 @@ template <class ValueType> class ConfigObject { | |||
return m_settingsPath; | |||
} | |||
|
|||
QList<ConfigKey> getKeysWithGroup(QString group); |
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.
Thats's why the mutex is declared as mutable
. I don't see any reasons why these functions cannot be declared as const
.
@uklotzde Done. |
c4859d3
to
243fb32
Compare
Merge? Then I could use my COVID-19 vacation tomorrow to implement the hotcue color replace dialog. |
@daschuer Merge? |
just waiting on @daschuer approval and then merge |
@daschuer
I'm quite certain that this doesn't make any difference because only the 3 least significant bytes will be used in all dependant code paths. But I can add the check if you want.
|
Thank you. The issue is not only the alpha channel, we will have also an issue if the double value overflows the 32 bit int. |
@@ -22,19 +23,39 @@ static const double CUE_MODE_NUMARK = 3.0; | |||
static const double CUE_MODE_MIXXX_NO_BLINK = 4.0; | |||
static const double CUE_MODE_CUP = 5.0; | |||
|
|||
constexpr double kNoColorControlValue = -1; |
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.
Ok, I will issue that in my follow up PR.
explicit ColorPalette(QString name, QList<mixxx::RgbColor> colorList) | ||
: m_name(name), | ||
m_colorList(colorList) { | ||
DEBUG_ASSERT(m_colorList.size() != 0); |
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.
We have RELEASE_ASSERT
woooooo! |
Can you add that to the list of to-do items on the Project board, so we don't forget about it? ;-) |
+1! love having things written down in easy-to-reference places |
This is yet another iteration of the hotcue color PR #2345 (and #2398 and #2399).
To Do (as separate PRs):
auto_hotcue_colors
option)