Custom Theme Configurator & Better Color Saving

[Reyatsu99]

My main motivation for this feature isn't that the current themes have wrong colors. I just wanted to have the flexibility to match exactly with my personal system themes without needing a hardcoded theme for every single aesthetic out there. The "Load Preset" feature was just meant for a quick baseline so we wouldn't have to define 50+ colors from scratch.

[matrohin]

Thank you for filing the issue!
Please let me know if you have any thoughts on what I'm suggesting below.

To correctly implement this we need to separate the internal state from the configurable state (to not break when we add something to our internal enum, or imgui adds something in the new version).
This means that we should have some limited amount of configurable colors, ideally not too many to keep the configuration manageable when updating (new UI element added -> we need to map to some pre-existing configurable color), but also easier for the user as well.

I'd be interested to know the depth of configuration that people actually need, right now I'm thinking of the following list (might be missing something though):

• surface - window background, etc
• panel - table header background, popup background, etc.
• field - tab, checkbox selected, etc.
• outline - borders.
• text - primary text color.
• text_muted - disabled text item, grayed rows, etc.
• accent - check-mark, button, etc.
• accent_strong - button active, header active, etc.
• red - error text, dead process row.
• green - new process row.
• warning - warning text.
• plot_colors[] - this will be an array of colors to use on the charts.

Some stuff we can delegate to compute (lerp(field, text, 0.08)).
BTW, this seems to be a good reference, although this is for editors, so I'd not use this directly: https://github.com/chriskempson/base16/blob/main/styling.md

I think this should be done in multiple steps (separate commits):

1. The settings saving / loading code is complicated right now and we need to refactor it before implementing this specific issue as this issue will use the settings heavily.
2. Unify the current color schemes to also match the new configurable colors.
   • This will be a good validation if the colors above are enough to express the current themes or not. It's OK of course to have built-in themes that are more complicated than what we allow the user to configure, but I'd strive towards consistency here.
   • Might be worth dropping enemymouse here, I added it for fun, and I didn't really use it and it's a bit strange in how we configure it.
   • Also it seems in the current themes we already forgot some of the colors, we should clean that up and assign all of them.
3. Implement the custom themes w/o the UI, just load them from settings.
   • a "base" theme + the colors above.
4. Implement the custom themes UI.

[Reyatsu99]

I think semantic palette idea is much better.
Your 4-step plan sounds perfect. Happy to help with any of the steps, just let me know where you want me to jump in (like the settings refactor, or if you want to lay the groundwork first).

[matrohin]

This sounds too much like AI again... I'm not against using AI. Please don't just copy AI-generated text for humans to read. It is disrespectful.
I (and an AI detection tool I double-checked with) might be wrong of course, you know what you did better than I do.

So for now please don't jump in. I'll get around this issue at some point.
You can continue using your fork with custom colors though, there is nothing wrong with that.