Can an app determine the current color scheme in its tab/pane?

[vefatica]

Can an app determine the current color scheme in its tab/pane?

Thanks!

[lhecker]

Do you mean the name of the scheme or just the colors?

[vefatica]

The name would suffice; so would an index (if I knew how they were indexed); so would both of those.

The settings dialog suggests that they're indexed in alphabetical order. (?)

[lhecker]

I cannot think of any approach that we'd consider "supported" right now. What I may try to do is to query the palette via VT sequences (OSC 4), open the settings.json file as well as the defaults.json file (part of the package), and try to match them. But that doesn't cover support for unpackaged Windows Terminal. You could theoretically dig deeper of course and e.g. find the Windows Terminal window and get its corresponding executable path. None of this sounds particularly robust to me unfortunately...

[vefatica]

I have the window handle. I (fancifully) imagined something like

SendMessage(hWndCascacia, WM_GET_SCHEME_INDEX, 0, 0)

How does the packaged/store version differ, with respect to color schemes, from my unzipped version?

[lhecker]

I have the window handle. I (fancifully) imagined something like [...]

That's theoretically something we could support, but I don't think I'd want to, because it would indirectly make it an official API that cannot be easily removed anymore. I'd only want to do that if there's a lot of people asking for it.

How does the packaged/store version differ, with respect to color schemes, from my unzipped version?

Oh, I just meant that you can't hardcode the path anymore in that case.

[vefatica]

Is there an OSC4 sequence for querying the palette?

[DHowett]

10-12 are strange, they don’t act like 4.

4 takes pairs of index and value (or query)

10-12 only take values (or queries), and they increment for every ;

so you would write

OSC 10 ; ? ; ? ; ? ST

but note that on Terminal 1.22+ you will also want to query for index 17. You can add a bunch more ;? Or you can ask for 17 specifically. :)

[j4james]

Unfortunately, 0xffff is meant to be equal to 0xff in that specification and 0x0c / 255.0 * 65535.0 roughly equals 0x0c0c. I kind of wish it was different, because if it worked like what you said it would be similar to the scRGB color range and allow us to specify actual HDR colors with VT sequences.

@lhecker I'm not sure if I've misunderstood what you're saying, but this format is actually intended to support HDR colors. FFFF is only interpreted as FF if your terminal is limited to 8-bit color components. For terminals that support 16-bit components, FFFF will in fact be interpreted as FFFF. In both cases they're essentially max brightness, but a 16-bit terminal allows you to distinguish between 256 levels in the range FF00 to FFFF, while an 8-bit terminal will consider all of those as the same intensity.

Last I checked, I think both VTE and Rxvt appeared to support 16-bit components. Or at least they were storing them that way internally, because I could round-trip 16-bit values. I'm not sure if I'd be able to tell whether they were actually rendered with that level of precision.

[lhecker]

But FFFF is meant to be the same brightness as e.g. \e[48;2;255;255;255m right? I'm not sure if there's a specification for it, but I think it's commonly assumed that the SGR colors are in sRGB, which means that OSC 4 colors would also be in sRGB? That would in turn mean that the 16-bit colors "only" add "color depth" (= more fidelity), but do not allow for HDR, which would require exceeding the dynamic range of sRGB.

[j4james]

Oh OK. I see what you're getting at now. Clearly I'm not a color expert. I was just thinking of HDR as more color depth. If you need to exceed the range of sRGB I guess we'd need a mode that could change the color space. I wonder if there any terminals that already have something like that.

[j4james]

Actually I just remembered there are a bunch of other color encoding formats supported by the OSC 4 and OSC 10 sequences that we could implement, like CIELab and TekHVC, and those take floating point components. Would something like that be good enough to get you the HDR range you want?

[vefatica]

Thanks, Dustin. I should have thought of that. I know all too well how to chain them when setting colors (i.e., don't use the 11 and the 12).

What's OSC 17?

Edit: Never mind that, it was easy to find. Are there others besides 10, 11, 12, and 17?

My goal was to identify the scheme. Tomorrow I'll look for a minimal set of OSC 4 and OSC 10+ values that ID the scheme. I reckon it'll be only a few. In a C program, where do I look for the responses ... stdin?

[lhecker]

In a C program, where do I look for the responses ... stdin?

Yep, after setting ENABLE_VIRTUAL_TERMINAL_INPUT.

[DHowett]

Are there others besides 10, 11, 12, and 17?

They're all in Thomas Dickey's excellent XTerm Control Sequences document.

To find these OSCs, search for Change VT100 text foreground (it will drop you in the middle of the list).

[vefatica]

Leonard, can I get the response with ReadConsole(GetStdHandle(STD_INPUT_HANDLE) ...?

Dustin, thanks for the link. I needed something like that. What's the status of OSC 19?

[vefatica]

Thank you, Leonard and Dustin. I have something that works. I'm querying the 20 colors separately. I can also do them all at once but so far separately is faster. I noticed something peculiar and I'd be pleased if you'd speculate on what's going on.

I do WriteConsole/WaitFor/ReadConsole 20 times (palette, FG, BG, cursor, selectBG, in that order). If I time them individually, I always see a pattern like this (below) which is striking. Any idea what's going on?

[DHowett]

Only if you don't allocate enough buffer!

[vefatica]

So the responses sent with one write operation ... eh?

[DHowett]

Yep! They sure are.

[vefatica]

Thanks. I'll go back to the all-in-one approach and try to come up with a faster way to parse the response.

It's still a mystery why the responses get quicker.

[vefatica]

That ain't so bad after all. Here's timing just the write/read.

And here's timing the write/read/parse.