Currently, the text colors of Spyder-Dark don't look too good, mostly because the color choices were designed around the light background and don't look good in the dark one. Furthermore, a major user desire on #2350 for their dark syntax theme to match the colors in the rest of the UI, etc. match those elsewhere in the UI so Spyder maintained a cohesive and seamless look. None of the built-in themes come even close, and have a number of related and other problems as well (full rationale reproduced below, for posterity's sake and to keep #8266 cleaner).
Therefore, I'd recommend replacing the current Spyder Dark colors with a much better set tuned to its new dark UI theme. As a matter of fact, I already have such a theme that I have been using across many different editors (Spyder, Rstudio, Notepad++, etc) and a myriad of document types for the past year and a half, and only needed a few minor tweaks to strategically pick up the appropriate colors from the rest of the UI for the new Spyder Dark theme.
What do you think about that as a starting point for replacing the current colors of the Spyder dark theme? Feedback or suggestions about where we should iterate from here @jnsebgosselin ?
The overall design is a sequence of red for keywords, orange for builtins, yellow for class and function definitions, light tan for instances, and finally white for variables and function calls, to create a conceptual hierarchy from fundamental constructs down to individual variables. Numeric literals are cyan and string literals are green for strings (to contrast well, and with colors matching their appearance in other themes and their conceptual "feel"), and comments are a desaturated mauve to look "lighter" than and clearly distinct from the rest of the executable content but still be very legible. Most of these colors also, incidentally, echo lighter versions of the ones used for the value column in the Variable Explorer.
Meanwhile, the background matches the pane background color, the side panels match the dark gray variable explorer name (and df index) column color (vs the standard foreground UI color) for a more subtle, modern look and better contrast with the line numbers, while the current line color matches the lighter gray in the type/size column and used for the background of objects, true/false in the VarExp Editors for something more visible at a glance that doesn't overly distract or reduce contrast on the text too much.
The occurrence color is a lighter and more cyan version of the standard selection color, to balance contrast with the dark background and with the light text colors, and balance distinctness and conceptual linkage with the main selection color. The cell color is a slightly darker and purpler version of the background, to both increase contrast and subtly draw the eye to the active cell, while maintaining a conceptual link to the purple-colored cell separator comments and horizontal rules. Finally, the matched and unmatched paren and link colors are just modestly lighter variations of what they are in the current dark theme, for easier visibility.
Here is the full theme, which can be pasted in your config file:
custom-1/background = #1a222f
custom-1/currentline = #31363b
custom-1/currentcell = #17172d
custom-1/occurrence = #509ea5
custom-1/ctrlclick = #179ae0
custom-1/sideareas = #222b35
custom-1/matched_p = #0bbe0b
custom-1/unmatched_p = #ff4340
custom-1/normal = ('#ffffff', False, False)
custom-1/keyword = ('#ff5855', False, False)
custom-1/builtin = ('#ffc341', False, False)
custom-1/definition = ('#ffff7f', True, False)
custom-1/comment = ('#aaaaff', False, False)
custom-1/string = ('#50ff50', False, True)
custom-1/number = ('#88ffff', False, False)
custom-1/instance = ('#dcb886', False, True)
custom-1/name = Spyder-Dark-V2
I encourage you to test each theme for yourself, since these small screenshots obscure a lot of smaller issues with each theme and make it difficult to fully grasp how they'd look full-size and full-screen.
@ccordoba12 Do you want me to link this to #8068 or not?
Yes, please. Thanks!
@CAM-Gerlach, I think your proposed changes are very similar to the Atom theme:
so I'd prefer that one instead. This is because the green and yellow you're using are too strong for my taste, whereas the Atom theme ones are lighter.
I think your proposed changes are very similar to the Atom theme:
Interesting coincidence, I'd never even heard of Atom when I originally came up with them and I've never actually seen Atom's native theme before you showed me that (since all I could readily find on their website was Atom skinned in various different colors). However, the basic design is indeed similar, although many of the specific color choices are different and Spyder's syntax highlighting likely behaves somewhat differently, at least from what I can see there. Its a good sign that its similar, since we want to it be pretty comparable to other modern editors/IDEs (Atom, VSCode, etc).
so I'd prefer that one instead.
Are you saying we should switch full-on, or just those two colors? If the former, any particular reason why we should switch full-on, other than the green and yellow being too intense (which I'm happy to fix)? For starters, if you can point me to some canonical source of the default theme colors for everything, I can create a Spyder theme based on those basic colors for us to look at and compare. As it stands, despite some Googling I can't find a clear resource that states them so I have no way of properly evaluating, never mind fully implementing this suggestion. Thanks!
This is because the green and yellow you're using are too strong for my taste, whereas the Atom theme ones are lighter.
Sure. The above image was a JPEG and so the colors aren't exact, but I could could measure them pretty closely with Photoshop and attempted to reproduce something similar in the current proposed theme. For the green, I dropped the saturation to near their lower value, and pushed the hues to something closer to their yellower tone. I didn't reduce the brightness down to their level, since it became a little hard to read.
As for the yellow, theirs actually had a higher saturation than those here, but I dropped the latter even further as well as a modest reduction in the brightness close to theirs. I only made a more modest shift in the hue (theirs is much closer to orange) because as you can see in the above screenshot, it is quite difficult to distinguish between that and orange, especially if they weren't right next to each other.
Let me know what you think:
Any particular reason why we should switch, other than the green and yellow being too intense (which I'm happy to easily fix)?
Yes. None of us is a graphics designer, so I really prefer to use an existing theme instead of trying to invent one by ourselves.
Furthermore, we would either make our default theme "Atom" which would be weird
The theme is called One Dark Pro
, so no Atom name would be involved:
https://marketplace.visualstudio.com/items?itemName=zhuangtongfa.Material-theme
I don't see the harm in it looking similar in principle (as it already does independently), but different in details, particularly considering a lot of those details need to be necessarily different because of the differences between the software and our dark theme palette
I don't see anything wrong with introducing differences in our theme to adapt it to our own palette.
For starters, if you can point me to some canonical source of the default theme colors for everything, I can create a Spyder theme based on those basic colors for us to look at and compare.
Please see the page I referenced above. It's GH repo has the theme colors and how they are applied.
I think you should open a PR for it, so we could continue the discussion there.
None of us is a graphics designer, so I really prefer to use an existing theme instead of trying to invent one by ourselves.
Great point. Its certainly good to take advantage of an existing design by someone with more expertise than us, if practicable, and it also helps people who are familiar with that popular theme to adapt more easily. On the other hand, compared with VSCode (which is built on very similar CSS/JS frameworks to Atom), it won't be entirely trivial to adapt it since I'll need to manually find and extract the relevant colors from the CSS and JSON, and a fair number the colors on our side don't either don't have direct equivalents, or are dictated by our different UI scheme (e.g. current cell, current line, background, side areas, occurrence, links...). Furthermore some colors, like comments, will likely then need to be tweaked to retain sufficient contrast with your background, cell, line and highlight/selection color.
The theme is called One Dark Pro, so no Atom name would be involved:
Thanks! FYI, ODP is the unofficial VSCode addon; the original version is called One Dark and is available here.
I don't see anything wrong with introducing differences in our theme to adapt it to our own palette.
Sure, we lose a lot of the benefits of adapting a single coherent theme created by a expert designer, and this solution tends to look more and more like the alternative, iterating what we have to adopt colors we like from One Dark where desired.
I think you should open a PR for it, so we could continue the discussion there.
Okay. What I could do is add both this theme and Atom's (with the needed baseline alterations/additions) and then we can compare them directly. If we end up going with this one (as Spyder-Dark or whatever), we can still keep One Dark as a user-selectable option, while if we got with one dark we can fixup the Git history to just remove Spyder Dark instead (since there's no point keeping it if it looks bad, isn't even coherent with our UI and isn't our default). What do you think @ccordoba12 @jnsebgosselin ?
and this solution tends to look more and more like the alternative, iterating what we have to adopt colors we like from One Dark where desired.
Yeah, we can't use plain One Dark because we need to adapt it to our needs.
What I could do is add both this theme and Atom's (with the needed baseline alterations/additions) and then we can compare them directly
Ok, I think that's a good plan.
@dalthviz, please work on this one. What we need here is:
If we've all firmly decided on that approach, we should also remove Spyder Dark
as part of this since it makes no sense to have as "our" theme one that A. looks, bad, and B. isn't even the default. We should also consider calling our version of One Dark something like "Spyder One Dark" since it will need substantial alternations from the original to match the Spyder UI as mentioned, and to make clear its not a modified version of the original adapted for Spyder and not officially endorsed by the creators (just like the unofficial VSCode port is called "One Dark Pro").
we should also remove Spyder Dark
Ok, no problem.
We should also consider calling our version of One Dark something like "Spyder One Dark"
Sure, no problem.
On a second thought, @dalthviz please work on top of the "Spyder dark" theme, i.e. don't remove it or rename it to "One dark".
On a second thought, @dalthviz please work on top of the "Spyder dark" theme, i.e. don't remove it or rename it to "One dark".
I dunno, but if we're directly taking their main text colors and using them for our own theme, it seems reasonable to give at least some credit where it is due and not represent it as our own entirely original theme, while still making clear its been customized for Spyder...but maybe there's another way to better represent this?
We could make a mention in About Spyder about this. It's the only place it occurs to me that could go.
Oh yeah we could, but that's mostly just for major or legally required things (CC-BY attributions and such) and it would lower the bar for inclusion there鈥擨'm sure you'll agree we don't want that to get too long and broad scope, as its both harder to see the important stuff and more work to maintain.
Either the title of the theme should properly reflect its origin, or we may as well not do anything鈥攊ts not really about the legal aspect. Either its a sufficiently derivative of One Dark, or its not, and the title is the primary place where that should be reflected.
Most helpful comment
Interesting coincidence, I'd never even heard of Atom when I originally came up with them and I've never actually seen Atom's native theme before you showed me that (since all I could readily find on their website was Atom skinned in various different colors). However, the basic design is indeed similar, although many of the specific color choices are different and Spyder's syntax highlighting likely behaves somewhat differently, at least from what I can see there. Its a good sign that its similar, since we want to it be pretty comparable to other modern editors/IDEs (Atom, VSCode, etc).
Are you saying we should switch full-on, or just those two colors? If the former, any particular reason why we should switch full-on, other than the green and yellow being too intense (which I'm happy to fix)? For starters, if you can point me to some canonical source of the default theme colors for everything, I can create a Spyder theme based on those basic colors for us to look at and compare. As it stands, despite some Googling I can't find a clear resource that states them so I have no way of properly evaluating, never mind fully implementing this suggestion. Thanks!
Sure. The above image was a JPEG and so the colors aren't exact, but I could could measure them pretty closely with Photoshop and attempted to reproduce something similar in the current proposed theme. For the green, I dropped the saturation to near their lower value, and pushed the hues to something closer to their yellower tone. I didn't reduce the brightness down to their level, since it became a little hard to read.
As for the yellow, theirs actually had a higher saturation than those here, but I dropped the latter even further as well as a modest reduction in the brightness close to theirs. I only made a more modest shift in the hue (theirs is much closer to orange) because as you can see in the above screenshot, it is quite difficult to distinguish between that and orange, especially if they weren't right next to each other.
Let me know what you think: