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

[XKit Preferences] Dark Mode Update 2 #2024

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

motackt
Copy link

@motackt motackt commented Dec 23, 2020

Redid #1848 with the current master.

Original Description:

Put in some logic (using checkboxes) for the XKit Control Panel to:

  • Match the current Tumblr colour palette. True Blue, Cement, and Canary all tell XKit to use the default light theme, while Dark Mode, Low-Contrast Classic, and Cybernetic all tell XKit to use this new dark mode.
    • So if the Tumblr colour palette changes, then the XKit Control Panel will update next time the user opens the Control Panel.
  • Always use dark mode regardless of current Tumblr colour palette.

Updated some class styles with items that weren't previously defined and so defaulted to black (not very clear against a dark background), and also added more variables because white box-shadows are not really a great design choice in dark themes.

xkit_dark
xkit_light
xkit_dark2

As a bonus, changed the default and kernel extension icons to SVGs for crispness and space!

Copy link
Member

@nightpool nightpool left a comment

Choose a reason for hiding this comment

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

Just a few quick notes—i don't have a lot of context on the current state of this code, i might not be the best person to review the rest of it

--xkit-11-overlay: rgba(0,0,0,.11);
--xkit-22-overlay: rgba(0,0,0,.22);
--xkit-33-overlay: rgba(0,0,0,.33);
--xkit-44-overlay: rgba(0,0,0,.44);
Copy link
Member

Choose a reason for hiding this comment

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

we're changing a lot of -shadow variable usage to -overlay in this PR. going forward, when would someone use -shadow vs using -overlay? is -shadow superfluous now?

Copy link
Author

@motackt motackt Dec 24, 2020

Choose a reason for hiding this comment

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

I replaced all --shadow variables that do not describe a box-shadow or text-shadow to be an --overlay instead. I did this for two reasons:

  1. It's more descriptive this way. --overlay denotes something that will colour the entire element (ie hovering over a tab), whereas --shadow is now only used for shadows (ie text-shadows and box-shadows).
  2. Dark Mode inverts the shadow colours (ie --shadow goes from black to white, and --white-shadow goes from white to black). But not all shadows should be inverted, such as --shadow (which goes from black to white) because it creates white box-shadows which look really odd because they're not as intuitive as black shadows). But some overlays are still useful, so I split them up into --shadow and --overlay so that I can invert --overlay while turning off --shadow.

If you don't do this (ie no --overlay variables and invert every shadow), then you get this result:

xkit_dark_white_shadows

Weird white box-shadows.

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

Successfully merging this pull request may close these issues.

2 participants