-
Notifications
You must be signed in to change notification settings - Fork 696
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
Colors: ColorSchemes
refactor - Should honor terminal color settings etc...
#2381
Comments
I was thinking about how a default theme could be dynamically created based only on an inherited foreground and background. This is quite difficult. FWIW, I thought I'd lay down my ideas. .Normal would just use the current colors, of course:
.Focus would just swap background and foreground [EDIT: though this collides with selection]:
.Disabled, I think, should compute a grayscale foreground color based on the background, adjusted for Luma. See Luma() below. We could use the following for RGB colors, or round to the nearest grayscale ConsoleColor (though see NB below):
.HotNormal is where things get tough:
To get an accent color, my first thought was to use an inverse of the RGB of the foreground color. However, this wouldn't work for middle-grayish colors, would often result in ugly combinations, and it wouldn't take Luma into account. It's somewhat easy to handpick a color for each of the 16 ConsoleColors like my AccentColor() implementation below, though this is obviously a matter of taste, and taking both foreground and background into consideration does complicate things quite a bit. AccentColor() would be somewhat more complicated using RGB (TrueColor or not), but I suppose the suggestions I offer below could still be used if we approximate numerically 16 zones of "reddish" or "dark-blueish" or "blackish" colors [something like the existing Color.ToConsoleColor()], but then we could adjust the accent result based on the calculated saturation and brightness. .HotFocus is similar, but swapping background and foreground:
However, we probably don't want to introduce another color which might clash with HotNormal, so we wouldn't just use NB: On the other hand, since each of the ConsoleColors can be set by the user and might even have little bearing on the actual color, it's dangerous to make assumptions. Even assuming the defaults were kept, there's variance between platforms and terminal emulations, e.g., whether bright colors are allowed as backgrounds. Under Windows, depending on the upgrade path the user might still be using legacy colors or the newer Campbell colors. However, is it even possible to programmatically determine the RGB values of the currently used colors? E.g., using Windows Terminal, we'd have to find and read the appropriate .json file; using Windows conhost, in some circumstances these values would be in the registry, and in some circumstances they'd be in the .lnk file used to launch it; with a multitude of implementations for other shells and platforms and terminal emulations. EDIT: Also, how is this supposed to work with the bitmap background? How do we ensure a transparent color is used so the bitmap isn't hidden when we've drawn spaces after, e.g., a window is dragged around? Does it just draw the bitmap anywhere the current background color exists? And I assume these implementation details could differ between shells...
|
Normally inverted colors is used for selection, like used in |
I was hoping to limit the number of accent colors to compute, but that's true. |
See PowerShell/ConsoleGuiTools#211 This request argues for being able to use PowerShell's $PSSytyle as a source for settings. |
ColorSchemes
refactor - Should honor terminal color settings etc...
Proposal for expanded
|
Relevant / informational: |
I think I mentioned it in the color discussion I started but in the spirit of that link, I'll link this project here, as well, as a potential resource for whatever we end up with: |
Developers (like me) love tweaking their terminal colors/themes.
Terminal.Gui, today, overrides all this, defining it's own themes.
This means that when I run a TUI app, the effect is glaring and doesn't honor all the hard work I put into tweaking my terminal theme. E.g.:
In addition we always clear the Toplevel background vs, letting any bitmap the user has set show through.
For v2, I'd like to see Terminal.Gui pick up the colors theme of the Terminal and use it, by default.
Of course, this implies we nail #48 too.
I think this means a Tenet for v2:
Other things that should be addressed as part of this:
ColorScheme
to be a value type (or similar). I spent an hour yesterday on an issue where I had donevar cs = colorScheme
vsvar cs = new ColorScheme(colorScheme)
.GetNormalColor
hackery - see v2 View drawing is forcing to always calling only the GetNormalColor () #2816The text was updated successfully, but these errors were encountered: