StylishThemes / GitHub-Dark

:octocat: Dark GitHub style
https://raw.githubusercontent.com/StylishThemes/GitHub-Dark/master/github-dark.user.css
BSD 2-Clause "Simplified" License
9.66k stars 654 forks source link

Theme request: Dark Purple 🦄 #910

Open bre7 opened 5 years ago

bre7 commented 5 years ago

.@OlyaB's theme recently added to IntelliJ's product suite

JetBrains' theme implementation: https://github.com/OlyaB/DarkPurpleTheme/blob/master/resources/themes/darkPurpleScheme.xml

Theme's license: MIT

the-j0k3r commented 5 years ago

Hello @bre7 and welcome!. Thanks for reaching out with this request =).

I edited your post to add a todo checklist, we would need this theme to be added to GitHub, Jupyter and Codemirror.

Any help you or anyone interested in this/other themes implementation, would be greatly appreciated =)

bre7 commented 5 years ago

Idea to automate theme conversion:

Map IntelliJ's theme <---> GH Dark using Solarized Dark as an example:

https://github.com/StylishThemes/GitHub-Dark/blob/master/themes/src/github/solarized-dark.css https://github.com/snowe2010/solarized-jetbrains/blob/master/resources/themes/solarizedDark.xml

the-j0k3r commented 4 years ago

@bre7 it would be nice to have some way of autogenerating a complete set of themes based on a common set of rules that define the same colors to its counter parts in the supported themes.

Currently I dont think there's any consistency across all 3 So really this is less than ideal.

Also Ive already proposed nuking all current themes that dont have all 3 counter parts in GitHub Dark (we can offer those as optional themes via an additional user style for these incomplete themes, nothing is lost for the users that dont mind, though this will be lower quality and not as good user experience with these enabled).

That will make maintaining the list of supported themes to a higher quality and in a consistent manner, but all that work is manual at this time and takes too much time.

We also need to remove selectors from main style that should be in the syntax themes, at the moment all diff colors and other elements work outside the syntax themes and dont match which lowers the quality of user experience considerably.

Ill see what design I can come up with for the colors soon as I figure out how we can compare how the syntax colors from CodeMirror match GitHub or Jupyter so all themes are consistent.

silverwind commented 4 years ago

I'd say extract all theme colors to CSS variables defined in JSON files, then build the usercss options from those files in usercss.js like

:root {
  --ghd-code-comment: #123;
  --ghd-code-keyword: #123;
  --ghd-code-property: #123;
}

Maybe I'll check this out later but removal of themes lacking support for all three variants can already be done now.

the-j0k3r commented 4 years ago

but removal of themes lacking support for all three variants can already be done now.

Yea, Ill make them optional in a separate style after.

I'd say extract all theme colors to CSS variables defined in JSON files, then build the usercss options from those files in usercss.js like

Yes, moving the colors to variables is one step, making the syntax themes across the 3 consistent, thats a diff ball game and one that is a must.

silverwind commented 4 years ago

I'd focus on making the github theme look good. The other two are rarely used and you can't make them perfect because of different tokenizers used.

the-j0k3r commented 4 years ago

We cant make them perfect, but we can make them look as good as possible. Just focusing on one is not where I saw this going as it solves nothing, except for who only uses one and doesnt care about the others.

What I had in mind was only 3 themes with the full CSS and then we only switch the root variables assigned for each theme the user selects, we dont need to dupe the CSS anymore, this alone should trim a gazillion duplicates. We only have to maintain the root values + what other grammars are added because they maybe missing.

I thought with the right approach we can have one single root var set for each color scheme and reuse colors for all 3 areas.

But to get there there's still work and I rather all 3 themes are up to snuff first.

Also the process of switching to root values, is that there will be a consistency of colors no matter which theme, so we eradicate one current evil also, as all of them were implemented differently.

One major challenge for me is to define a standard grammar for each theme, we currently have templates, but a lot of our themes have more selectors and some less than the templates. So the real main challenge is define really good solid templates with the actual needed CSS.

For that last part I really would need help, for the rest I can handle it.

Heck, Im not even sure we need to include anything in GitHub Dark, I would rather do it separately, ideally, if a user selects ambiance, then ALL themes should be set to ambiance and not select the themes individually. We cant do that in GitHub Dark because we dont support any decent preprocessors that allow this.