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

Feature request: generate block colors based on current editor background. #14

Open
szyszak opened this issue Jun 12, 2021 · 9 comments

Comments

@szyszak
Copy link

szyszak commented Jun 12, 2021

I'm currently using "Winter Is Coming (Dark Blue - No Italics)" theme, which has a dark blue background, that doesn't look good with any of current presets.
I know that I can set block colors myself in the settings, but it would be nice if this extension could dynamically generate block colors based on current editor theme.

Przechwytywanie

@leodevbro
Copy link
Owner

leodevbro commented Jun 12, 2021

Well, it is not a hard task, but it is time consuming, because we need to build a library of references of vscode themes and Blockman color combos, and there are many vscode themes, so it will take time. I hope to make it in the near future. But, there is one good thing, if vscode theme is light, Blockman will set color combo to Light (Only at the first installation, then needed manual adjustment).

@szyszak
Copy link
Author

szyszak commented Jun 13, 2021

I was thinking more about something like this:

  1. Detect current editor background color.
  2. Generate a color palette using this color as base.

I imagine that the color generating function would take one color and return an array of colors. Every color in sequence would be 10% lighter/darker (depends if theme overall is light or dark) than the previous one and color at index of 0 would be the first level block, 1 will be the nested block and so on.

I don't know much about design and colors, so my way of thinking may not make any sense.

@codemangle101
Copy link

codemangle101 commented Jun 14, 2021

My suggestion is why not use some thing like dark/bright color with different opacity levels for nested blocks ? This doesn't require keeping track of theme name that's being used. Dark/Bright background may be detected or ask the user about the choice or let the user configure it in settings.

@MHHenriksen
Copy link

My suggestion is why not use some thing like dark/bright color with different opacity levels for nested blocks ? This doesn't require keeping track of theme name that's being used. Dark/Bright background may be detected or ask the user about the choice or let the user configure it in settings.

I can see two potential (but possibly small or solvable) issues: Performance of alpha blending (especially multilayer), and general color theory which I apologize but don't have time to elaborate, colors aren't as easy to interpolate as you'd think, just do a quick google search on color space theory to get an idea. But I suppose for the purpose of this extension, that last part is probably overthinking it.

Still, my advice would be to prefer @szyszak's suggestion and explore that first

@vamseekm
Copy link

My suggestion is why not use some thing like dark/bright color with different opacity levels for nested blocks ? This doesn't require keeping track of theme name that's being used. Dark/Bright background may be detected or ask the user about the choice or let the user configure it in settings.

I can see two potential (but possibly small or solvable) issues: Performance of alpha blending (especially multilayer), and general color theory which I apologize but don't have time to elaborate, colors aren't as easy to interpolate as you'd think, just do a quick google search on color space theory to get an idea. But I suppose for the purpose of this extension, that last part is probably overthinking it.

Still, my advice would be to prefer @szyszak's suggestion and explore that first

Yes, @szyszak suggestion looks like most sensible. For some reason I didn't read his/her comment and was replying to comment above his/her's in haste. Thank you.

@leodevbro
Copy link
Owner

leodevbro commented Jun 15, 2021

I was thinking more about something like this:

  1. Detect current editor background color.
  2. Generate a color palette using this color as base.

I imagine that the color generating function would take one color and return an array of colors. Every color in sequence would be 10% lighter/darker (depends if theme overall is light or dark) than the previous one and color at index of 0 would be the first level block, 1 will be the nested block and so on.

I don't know much about design and colors, so my way of thinking may not make any sense.

Maybe we can detect current vscode background color, but generating color array based on this color is hard to be universal. I mean, we can easily generate +10% lighter/darker colors, but for how many depths maximum? If we make 4 depths, and the base color is already relatively lightened/darkened, then the generated 4th depth color will be too light/dark to read the text and will be super uncomfortable. Maybe we can set maximum lightness, for example 40%, but it is still not the universal solution because our eyes perceive lightness differently with different color hues. So, 40% light green will not be the same light as 40% light blue for our eyes; There are some color formats that try to simulate our eye perception for lightness with color hues, but they are not super accurate and maybe not supported vscode API css values.

So the solution is a heavy research for color-hue-lightness perception and adjust it with vscode background color as a base color.

I hope I will have time for such research in the near future.

Before that, I think spending several minutes to go to Blockman settings and adjust each-depth color manually is not a deal breaker when Blockman helps us to read code with a big comfort.

@CWempe
Copy link

CWempe commented Jun 19, 2021

I just learned about blockman and installed it.

image

This is a simple markdown file.
My first thoughts were:

  • Why does blockman look for blocks in a text/markdown file?
    Should I create a separate issue for excluding custom languages from blockman?
    Unfortunately you cannot disable addons per language.
  • Why is there a block when there are only 5 lines of simple text?
    I think Depth0 should not be highlighted as a block per default.
    Should I create a new issue for this, too?
  • Why is the Depth0 block not my default background color?
    If Depth0 is considered a block, I think it should have the background color of my theme.
    Why would a user want most of his code be on a different background color than the installed theme defines.

So I support the idea to use the default background color as a base and add like 10% darkness/brightness to each level. (I understand it is not that simple.)

Anyway, I think this addon is great and I will configure custom colors as a workaround for my use. 👍

EDIT:
OK, I may have posted to early. 😄

  • I set Option N04 Color Combo Preset to Classic Dark Oppo )Gradient) wich seems set the colors I wanted.
  • I also set Option N05 and N20 to none as explained here, to disable Depth0.
    I am happy now. 😃

@MHHenriksen
Copy link

Allow me to argue against myself for a moment :P I was definitely overthinking it. This is a case of a giant research project to get it perfect vs a one hour quick fix to get it much better than it already is, and I know which of those two options I would do first.

I think a decent solution would be to split it into 4 cases to cover by dividing the brightness scale into 4 equal pieces, and using different patterns for each segment. And it sounds like you would already know but it should be easy to find some formula to approximate brightness, or just color space conversion to for example HSL/HSV which also makes it easy to adjust the value instead of interpolating RGB, I'd bet VS Code SDK has builtin functions for it even, remember: trade perfect for finished.

  • Dark: +10% +20% +30%...
  • Dim: -20% -10% 0% +10%... (this would look like the examples in the readme)
  • Bright: +20% +10% 0% -10%...
  • Burning: -10% -20% -30%...

This guarantees you can do at least 7 levels, which is probably enough for default settings. And it's of course possible to tweak the numbers, like smaller increments, different start offsets for dim/bright, different cutoffs between cases.

But all of that is polish that can be done in separate later iterations, and at that point you might also have the benefit of user feedback :D I'm already imagining the next issue where I ask for this autogen to be user controllable either as a group of settings (that you could still override and manually set specific colors per layer) or as a separate tool, where you can set those values yourself, and select curves instead of linear, and even control hue and saturation, rainbow mode anyone?!

@leodevbro
Copy link
Owner

I released a new version (1.3.0) of Blockman. I think some of the new features partially solve this issue (N14).

[1.3.0] - 2021-11-10

  • Added ability in Blockman settings to choose preferred color combos for Dark, Light and High Contrast theme kinds.
  • Borders now support gradient value too, e.g. linear-gradient(to right, red, blue)
  • Added two color combos with gradient borders (Super gradients)
  • Large changes made on the peformance optimization structures

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

No branches or pull requests

6 participants