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

Key Colors for the Key text in the decks #13608

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

danferns
Copy link
Contributor

This is a WIP PR for adding key colors to the UI of the decks.

Initially I had tried setting the background color of the label to the key color, but we found that we needed something more subtle. So we decided to go for a small colored rectangular bar next to the text, just like in the library key column.

@github-actions github-actions bot added the ui label Aug 28, 2024
Comment on lines +3 to +4
#include <qboxlayout.h>
#include <qevent.h>
Copy link
Member

Choose a reason for hiding this comment

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

Why not

Suggested change
#include <qboxlayout.h>
#include <qevent.h>
#include <QBoxlayout>
#include <QEvent>

like elsewhere?

@ronso0
Copy link
Member

ronso0 commented Aug 29, 2024

Thanks for your continuous work on this!

It doesn't build, did you forget to commit something?
Why a WidgetGroup (that doesn't seem to be set up), doesn't it suffice to set a stylesheet with color and background color?

@daschuer
Copy link
Member

This is a midair PR, I have requested to wrap up GSoC.
We are unsure what is the best approach here visually.
Maybe we should collect first design mockups and than continue here?

@ronso0 what do you think. Is coloring the background the right approach? How to deal with off-tune pitches?
Alternative: a border or a separate box.

One idea was to fade out the color in the range of 10 to 20 ct off and show no color for tracks not on the key wheel.

@ronso0
Copy link
Member

ronso0 commented Aug 29, 2024

Ah okay, I wasn't aware of the context, thanks for the clarification.

AFAIK the key-related design process happend on Zulip, so maybe we should stick to that, idk.

I agree with the color bar approach as mentioned in the description. A for consistency with the library's key column, B a distinct spot/area with information, compared to a (dimmed) colored area where the color information maybe affected by a contrasting text. It'd also be consistent with the track color bar in the decks.

What information do I expect from the key widget? (none actually since I don't use it ...)
Before mixing tracks the decks' key color should tell me at a glance whether tracks are compatible. So basically: same color = match. The more advanced method would require having a scheme of compatible colors in mind, for example like green matches yellow and bright blue.
I imagine it to be helpful indeed that, if they is off by XX cents after pitch shifting, the color should fade significantly.
Maybe we can incorporate a slider-like marker on the bar to indicate the position related to the current key. (= visual_key_distance control like in Shade skin. For feedback, not for control).

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

Successfully merging this pull request may close these issues.

3 participants