Simplify the color palette APIs #11768
Labels
Area-CodeHealth
Issues related to code cleanliness, linting, rules, warnings, errors, static analysis, etc.
Area-Server
Down in the muck of API call servicing, interprocess communication, eventing, etc.
Issue-Feature
Complex enough to require an in depth planning process and actual budgeted, scheduled work.
Needs-Triage
It's a new issue that the core contributor team needs to triage at the next triage meeting
Product-Conhost
For issues in the Console codebase
Resolution-Fix-Committed
Fix is checked in, but it might be 3-4 weeks until a release.
Description of the new feature/enhancement
At the moment, the
ConGetSet
andITerminalApi
interfaces have a bunch of different methods for setting color palette entries. There's aSetColorTableEntry
, aSetCursorColor
, aSetDefaultForeground
, and aSetDefaultBackground
. If we want to support the OSC color queries (#3718), we're going to need to add equivalent getter methods for each of these colors. And at some point we'll probably want add support for things like the selection colors, and bold color (#5682), each of which will also require setter and getter methods.My proposal is we simplify this to just two methods:
SetColorTableEntry
andGetColorTableEntry
, which can then be used to access any of the configurable color values, and not just the 256-color table.Proposed technical implementation details (optional)
The way this would work, is we'd extend the 256-color table with additional entries on the end for the special colors, and define a few constants to reference those entries.
So instead of calling a unique method like
SetDefaultForeground(color)
, you'd just be doing something likeSetColorTableEntry(TextColor::DEFAULT_FOREGROUJD, color)
.One of the advantages of this approach, is that it simplifies the interpretation of the default colors in conhost. Right now a default color can either be an index in the color table, or a completely separate value. With this new approach it'll always be somewhere in the color table - you just need to store the actual index.
And note that support for index-based default colors is something that we'll need for VT525 emulation at some point, so in the long term it won't just be a conhost thing.
I also have a sneaking suspicion that this might help us get rid of the PowerShell color quirk (#6807), or at least simplify it, but I can't promise that.
The text was updated successfully, but these errors were encountered: