The only alternative to System.Drawing.Color built on actual color theory
Because color management shouldn't require a PhD in color theory
Overview
KtColor is a complete color management system for .NET WinForms that replaces the limitations of System.Drawing.Color with a developer-friendly API built on HSL color theory, variable theming, and intuitive syntax.
Why KtColor Exists
System.Drawing.Color was designed for basic color representation, not modern UI development:
No color theory support - RGB values don't map to how humans perceive color
No theme system - Can't define semantic colors like "Primary" or "Success"
No shade generation - Manual calculation of lighter/darker variants
Poor string parsing - Limited format support
No opacity management - Alpha channels are awkward to work with
KtColor solves these problems with a unified system built for human perception and modern theming.
Core Concepts
1. Color Representation
KtColor uses HSL (Hue, Saturation, Lightness) internally because it matches human color perception:
2. Three Color Types
Native Colors - Predefined palette colors with names:
Custom Colors - From hex, RGB, or System.Drawing.Color:
Empty/Transparent:
Palette System
Base Colors (Neutrals)
Accent Colors (Main Palette)
Theme Variables
Shade System
Every palette color includes 11 shades (0-100 in 10% increments):
String Format Support
Parsing Formats
Rendering Formats
Operators Reference
Implicit Conversions
Lightness Operations
Opacity Operations
Color Inversion
Conditional Operations
Color Mixing
Comparison
Boolean Context
Property Inspection
Color Properties
State Checks
Theme System
Setting Theme Variables
Theme Change Events
Default Theme Colors
Dark Mode (default):
Light Mode:
Advanced Features
Content Color Calculation
Automatic foreground color for any background:
Opaque Color Blending
Flatten translucent colors onto a background:
Color Iteration
Enumerate all shades:
Random Colors
Design Decisions
Why HSL over RGB?
Human perception - HSL maps to how humans naturally think about color:
"Make it lighter" โ Increase L
"More vibrant" โ Increase S
"Change the color" โ Adjust H
RGB requires mental math to achieve these effects. With RGB, making a color "lighter" means adding white to all channels proportionally, which is unintuitive.
Predictable shades - In HSL, generating a lighter shade is trivial:
Consistent brightness - All colors at the same L value have perceptually similar brightness, making UI consistency easier.
Why String-Based Palette Names?
Using strings ("Blue") instead of enums provides:
Extensibility - Add custom colors without recompiling
Serialization - Natural JSON/config file support
Dynamic theming - Runtime color palette switching
Designer support - PropertyGrid string editor works out of the box
The trade-off is type safety, mitigated by:
TryParsefor validationStatic properties for common colors (
KtColor.Blue)IntelliSense support through static members
Why Variable System?
Theme variables ($Primary, $Base) solve a fundamental problem in UI development: semantic colors.
Traditional approach:
Problems:
Can't change brand colors without find-replace
No dark mode support
Inconsistent colors across components
Can't theme at runtime
KtColor approach:
Why Operator Overloading?
Operators make color manipulation read like natural language:
The code becomes self-documenting. color + 10 obviously means "lighter", color % 50 clearly indicates opacity.
Performance Considerations
Lazy Evaluation
KtColor uses lazy property evaluation to minimize allocations:
Once calculated, values are cached. This means:
Creating
KtColor.Blueis cheap (no calculations)First
.Render()call performs HSLโRGB conversionSubsequent renders use cached value
Theme Variable Invalidation
When theme variables change, cached values are invalidated via hash code:
This ensures theme changes propagate while maintaining performance during normal operation.
Allocation Patterns
Best practice: Store KtColor in properties, render only when needed for painting.
Integration Patterns
PropertyGrid Support
Full designer integration via TypeConverter:
The PropertyGrid shows:
Dropdown with standard values
String editor for custom values
Color picker for RGB colors
Live preview of the color
Custom Editor
KtColor includes a custom color editor that extends the standard .NET color picker:
Features:
Palette color browser
Shade selector
Opacity control
Search functionality
Theme variable access
JSON Serialization
Implicit JToken conversion for JSON.NET:
Deserialize back:
Migration Guide
From System.Drawing.Color
From String Color Names
Adding Theme Support
Best Practices
1. Use Theme Variables for Semantic Colors
2. Store KtColor, Render Late
3. Use Operators for Variations
4. Leverage Content Colors
5. Subscribe to Theme Changes
Common Pitfalls
1. Comparing Rendered Colors
2. Losing Shade Information
3. Not Handling Empty Colors
4. Ignoring Opacity in Rendering
API Summary
Static Properties
22 palette colors:
Slate,Blue,Red, etc.11 theme variables:
PRIMARY,BASE,CONTENT, etc.Special:
Empty,Transparent,White,Black
Instance Properties
RGB:
R,G,B,AHSL:
Hue,Saturation,Lightness,ShadeState:
IsEmpty,IsOpaque,IsNative,IsVariableMeta:
Name,Base,Opacity
Static Methods
Parse(string)- Parse any color formatTryParse(string, out KtColor)- Safe parsingRender(bool? isDark)- Set theme@default(string, Color)- Set variableMix(c1, c2, percentage)- Blend colorsRandom(shade?)- Random color
Instance Methods
Render()- Convert to System.Drawing.ColorToString()- KtColor string representationHex(),RGB(),HSL(),Web()- Format conversionInvert(),Content(),Mirror()- Color transformsOpaque(background)- Flatten alpha
Operators
+,-- Adjust lightness%- Set opacity/- Divide opacity!- Invert~- Auto-contrast|- Coalesce==,!=,<,>- Compare
KtColor - Because color management shouldn't require a PhD in color theory
Last updated
Was this helpful?

