summaryrefslogtreecommitdiff
path: root/patches/screen-4.0.3-sys_adopt-on-attach.patch.txt
diff options
context:
space:
mode:
authorVito Caputo <vcaputo@pengaru.com>2025-05-04 17:39:05 -0700
committerVito Caputo <vcaputo@pengaru.com>2025-05-04 17:47:46 -0700
commiteeaa389328bd8e7d4b3a1954e1d18978162fed42 (patch)
treede3adaefe60e3db970fa98cdf13bbabcde54679f /patches/screen-4.0.3-sys_adopt-on-attach.patch.txt
parent55fdd41ae125fd12d6e8deec493037469d1c0888 (diff)
vcr: fill out the available PNG graph colors
I've picked some colors just to have /something/ populating these. For now only the first two (red and cyan) are being used, but subsequent commits will wire these up to a per-row palette selector which the charts code will set appropriately and vcr will need to consult when presenting the charts to png/X. It's tempting to make the colors user-definable at run-time. But that actually seems like a bad idea. Instead, I expect to iterate on these until a Good Enough set of colors is arrived at, then leave them hard-coded in the source. Why? you may ask... well, it's simple - I want everyone using vmon to develop a familiarity with grokking the output in a way that's consistent and transferrable if they encounter it elsewhere, or if people pass around the snapshots / attach them to GH/JIRA tickets etc. We shouldn't need a decoder wheel to understand what the colors mean to a given use case. The source defines the meaning of the colors, and once the dust settles, it should try stay as consistent as possible.
Diffstat (limited to 'patches/screen-4.0.3-sys_adopt-on-attach.patch.txt')
0 files changed, 0 insertions, 0 deletions
© All Rights Reserved