enlightenment/terminology
enlightenment
/
terminology
9
6
Fork 7
Code Issues 7 Pull Requests Projects Releases Wiki Activity

Responses to Queries for the Foreground and Background Color Use Different Format #14

New Issue
Open
opened 2024-03-15 08:08:38 -07:00 by bash · 5 comments
bash commented 2024-03-15 08:08:38 -07:00
Copy Link

While testing my terminal-colorsaurus library I noticed that the Terminology responds with two different formats to color queries using OSC 10 / OSC 11:

  • OSC 10: Terminology responds with a CSS-like hex format (e.g. #AAAAAA)
  • OSC 11: Terminology responds with the XParseColor format (e.g. rgb:2020/2020/2020)

This surprised me, as most other terminals respond with the XParseColor format to both OSC 10 and OSC 11. For reference here are some terminals that I have tested.

Is the current behaviour intentional? I would be open to submitting a PR to change the OSC 10 response to also use the XParseColor format.

Here are the two commands that I used to test the response:

printf '\e]10;?\a' # OSC 10
printf '\e]11;?\a' # OSC 11
While testing my [`terminal-colorsaurus`] library I noticed that the Terminology responds with two different formats to color queries using `OSC 10` / `OSC 11`: * `OSC 10`: Terminology responds with a CSS-like hex format (e.g. `#AAAAAA`) * `OSC 11`: Terminology responds with the XParseColor format (e.g. `rgb:2020/2020/2020`) This surprised me, as most other terminals respond with the XParseColor format to both `OSC 10` and `OSC 11`. For reference [here][terminal-survey] are some terminals that I have tested. Is the current behaviour intentional? I would be open to submitting a PR to change the `OSC 10` response to also use the XParseColor format. Here are the two commands that I used to test the response: ```bash printf '\e]10;?\a' # OSC 10 printf '\e]11;?\a' # OSC 11 ``` [`terminal-colorsaurus`]: https://github.com/bash/terminal-colorsaurus [terminal-survey]: https://github.com/bash/terminal-colorsaurus/blob/main/doc/terminal-survey.md
raster commented 2024-03-15 15:51:26 -07:00
Owner
Copy Link

You might want to check the manual page for XParseColor ... :) You do know why CSS/web support #RRGGB ... it's because web browsers originate on unix... mosaic (whyich gave birth to netscape which begat...) ... and it supported #RRGGBB ... because this is what XParseColor would support - or for that matter this was how you defined colors in X. I assume you didn't grow up with X int he 80's and 90's like me :). It's why you can also use Black,White or even Burlywood (and more string names) as X color names. So in addition to rgb:RRRR/GGGG/BBBB the above "CSS" names as well as just string color names are supported by XParseColor ... they are all valid color strings in they eyes of X11 and XParseColor and thus where all these color defs come from in both color X terminal emulation and in web - they all originate from X11's color specs and XParseColor... so... they are all valid :)

terminology is keeping you in your toes :)

You might want to check the manual page for XParseColor ... :) You do know why CSS/web support #RRGGB ... it's because web browsers originate on unix... mosaic (whyich gave birth to netscape which begat...) ... and it supported #RRGGBB ... because this is what XParseColor would support - or for that matter this was how you defined colors in X. I assume you didn't grow up with X int he 80's and 90's like me :). It's why you can also use Black,White or even Burlywood (and more string names) as X color names. So in addition to rgb:RRRR/GGGG/BBBB the above "CSS" names as well as just string color names are supported by XParseColor ... they are all valid color strings in they eyes of X11 and XParseColor and thus where all these color defs come from in both color X terminal emulation and in web - they all originate from X11's color specs and XParseColor... so... they are all valid :) terminology is keeping you in your toes :)
❤️ 1
bash commented 2024-03-16 03:14:55 -07:00
Author
Copy Link

Oh wow, thank you for that prompt and illuminating answer! I should probably work on my man page reading skills :))

I assume you didn't grow up with X int he 80's and 90's like me :)

hehehe you got me there :)

Oh wow, thank you for that prompt and illuminating answer! I should probably work on my man page reading skills :)) > I assume you didn't grow up with X int he 80's and 90's like me :) hehehe you got me there :)
bash closed this issue 2024-03-16 03:14:57 -07:00
raster commented 2024-03-16 16:37:43 -07:00
Owner
Copy Link

:) having been there, done that.. i knew #RRGGBB was originally an x color spec.. long before css/web existed :) anyway... all good - things to know/learn and add to your terminal-colorsaurus :) don't forget to ALSO handle x11 color names (like Burlywood) https://en.wikipedia.org/wiki/X11_color_names

:) having been there, done that.. i knew #RRGGBB was originally an x color spec.. long before css/web existed :) anyway... all good - things to know/learn and add to your terminal-colorsaurus :) don't forget to ALSO handle x11 color names (like Burlywood) https://en.wikipedia.org/wiki/X11_color_names
bash commented 2024-03-17 07:54:34 -07:00
Author
Copy Link

:)) Yeah I have been mulling over whether or not to add support for the x11 color names...
It's part of what XParseColor accepts and some terminals might thus respond with a color name.
On the other hand though, I haven't observed this in practice. Even xterm always responds with rgb:, even when I set the color using a color name...

printf '\e]11;rebecca purple\a'
printf '\e]11;?\a' # xterm responds with: "]11;rgb:6666/3333/9999"

Well I might add it anyways just in case :)

:)) Yeah I have been mulling over whether or not to add support for the x11 color names... It's part of what `XParseColor` accepts and some terminals might thus respond with a color name. On the other hand though, I haven't observed this in practice. Even xterm *always* responds with `rgb:`, even when I set the color using a color name... ```bash printf '\e]11;rebecca purple\a' printf '\e]11;?\a' # xterm responds with: "]11;rgb:6666/3333/9999" ``` Well I might add it anyways *just* in case :)
bash commented 2024-03-19 14:04:02 -07:00
Author
Copy Link

After surveying a ... ummm couple 😅 ... of terminals on how they answer to OSC 10 / OSC 11 queries I am inclined to open this issue again. Almost all terminals that I have looked at only respond with the rgb: format even though they accept multiple formats when setting the colors using OSC 10 / OSC 11.

Wouldn't it make sense to follow that pattern?

Here are the terminals that I have looked at.
All of them use the rgb:rrrr/gggg/bbbb format when responding to queries.

What do you think?

  1. Can be configured to use 8-bit color values. ↩︎

  2. Not open source, so I had to test a couple of cases myself. ↩︎

  3. Responds with rgba:<r>/<g>/<b>/<a>, 16-bit if the color has an alpha channel ↩︎

After surveying a ... ummm couple 😅 ... of terminals on how they answer to `OSC 10` / `OSC 11` queries I am inclined to open this issue again. Almost all terminals that I have looked at *only* respond with the `rgb:` format even though they accept multiple formats when setting the colors using `OSC 10` / `OSC 11`. Wouldn't it make sense to follow that pattern? Here are the terminals that I have looked at. \ All of them use the `rgb:rrrr/gggg/bbbb` format when responding to queries. * [xterm.js][xterm.js-src-2] * [iTerm2][iterm2-src-2] [^1] * Terminal.app [^2] * [Alacritty][alacritty-src-2] * [Contour][contour-src-2] * [vte][vte-src-2] * [Konsole][konsole-src-2] * [foot][foot-src-2] * [WezTerm][wezterm-src-2] * [kitty][kitty-src-2] * [Rio][rio-src-2] * [rxvt-unicode][rxvt-src] [^3] * [tmux][tmux-src-2] * [mintty][mintty-src-2] * [Termux][termux-src-2] * [st][st-src-2] [^1]: Can be configured to use 8-bit color values. [^2]: Not open source, so I had to test a couple of cases myself. [^3]: Responds with `rgba:<r>/<g>/<b>/<a>`, 16-bit if the color has an alpha channel [hterm-src]: https://chromium.googlesource.com/apps/libapps/+/HEAD/libdot/js/lib_colors.js#175 [xterm.js-src]: https://github.com/xtermjs/xterm.js/blob/9ec9dca5f8ca8e1f107f7cf4c8a545672e8f69c4/src/common/input/XParseColor.ts#L23 [iterm2-src]: https://github.com/gnachman/iTerm2/blob/691fd5dd8c7dd7606becee320ece1648152af6c0/sources/VT100Terminal.m#L3729 [alacritty-src]: https://github.com/alacritty/vte/blob/ed51aa19b7ad060f62a75ec55ebb802ced850b1a/src/ansi.rs#L184 [contour-src]: https://github.com/contour-terminal/contour/blob/521b1408600951b63b285ff459f6fc6e9fbf6806/src/vtbackend/Color.cpp#L132 [konsole-src]: https://invent.kde.org/utilities/konsole/-/blob/0880a2137be8907ec06ba96918753735790c02fc/src/session/Session.cpp#L617 [QColor]: https://github.com/qt/qtbase/blob/e146d835a69d57748bf2978cf5134ac5d86d81cf/src/gui/painting/qcolor.cpp#L980 [SVG color keyword names]: https://www.w3.org/TR/SVG11/types.html#ColorKeywords [foot-src]: https://codeberg.org/dnkl/foot/src/commit/5f41eb798b639774d5cb2a7656fbaf4c61a16352/osc.c#L711 [wezterm-src]: https://github.com/wez/wezterm/blob/889f8a9cd71a2b3552f28f6d1864aa3cd9461fdf/color-types/src/lib.rs#L657 [css colors]: https://docs.rs/csscolorparser/latest/csscolorparser/ [kitty-src]: https://github.com/kovidgoyal/kitty/blob/3c19b6f734349249c014c97324011217eae63867/kitty/rgb.py#L60 [rio-src]: https://github.com/raphamorim/rio/blob/be139e9e847d4c967086a88dde951a32c2464aed/rio-backend/src/performer/handler.rs#L39 [rxvt-src]: http://cvs.schmorp.de/rxvt-unicode/src/command.C?view=markup#l3440 <!-- rxvt source code hint: look at process_color_seq --> [tmux-src]: https://github.com/tmux/tmux/blob/b79e28b2c30e7ef9b1f7ec6233eeb70a1a177231/colour.c#L965 [terminology-src]: https://git.enlightenment.org/enlightenment/terminology/src/commit/3c967f3379b71e6c563e917784afe96470b75259/src/bin/termptyesc.c#L4022 [mintty-src]: https://github.com/mintty/mintty/blob/b9384e0cdf999be0b5ba4b7fc2f74eda0080bdc1/wiki/Tips.md#changing-colours [come from mintty]: https://github.com/tmux/tmux/issues/2567 [mintty-src-2]: https://github.com/mintty/mintty/blob/b9384e0cdf999be0b5ba4b7fc2f74eda0080bdc1/src/termout.c#L4048 [xterm.js-src-2]: https://github.com/xtermjs/xterm.js/blob/9ec9dca5f8ca8e1f107f7cf4c8a545672e8f69c4/src/common/input/XParseColor.ts#L77 [iterm2-src-2]: https://github.com/gnachman/iTerm2/blob/b202da066446e3e3875c3daeb4bcad8327338364/sources/VT100Output.m#L1136C37-L1136C57 [alacritty-src-2]: https://github.com/alacritty/alacritty/blob/fe88aaa0855283d689dc41d531db916404ef9c51/alacritty_terminal/src/term/mod.rs#L1644 [contour-src-2]: https://github.com/contour-terminal/contour/blob/521b1408600951b63b285ff459f6fc6e9fbf6806/src/vtbackend/Sequencer.h#L96 [konsole-src-2]: https://invent.kde.org/utilities/konsole/-/blob/882291ad3bf14f719dca9d4694ed1b609447371c/src/session/Session.cpp#L888 [foot-src-2]: https://codeberg.org/dnkl/foot/src/commit/5f41eb798b639774d5cb2a7656fbaf4c61a16352/osc.c#L698 [rio-src-2]: https://github.com/raphamorim/rio/blob/be139e9e847d4c967086a88dde951a32c2464aed/rio-backend/src/crosswords/mod.rs#L1389 [wezterm-src-2]: https://github.com/wez/wezterm/blob/889f8a9cd71a2b3552f28f6d1864aa3cd9461fdf/termwiz/src/color.rs#L132 [kitty-src-2]: https://github.com/kovidgoyal/kitty/blob/a0424bf1bd7187fe6017ec118c3c9318e8b28920/kitty/window.py#L1176 [terminology-src-2]: https://git.enlightenment.org/enlightenment/terminology/src/commit/3c967f3379b71e6c563e917784afe96470b75259/src/bin/termptyesc.c#L4290 [terminology-src-3]: https://git.enlightenment.org/enlightenment/terminology/src/commit/3c967f3379b71e6c563e917784afe96470b75259/src/bin/termptyesc.c#L4245 [tmux-src-2]: https://github.com/tmux/tmux/blob/b79e28b2c30e7ef9b1f7ec6233eeb70a1a177231/input.c#L2556 [termux-src]: https://github.com/termux/termux-app/blob/8e3a8980a849046adbd4156741e1d84047ee1df6/terminal-emulator/src/main/java/com/termux/terminal/TerminalColors.java#L37 [termux-src-2]: https://github.com/termux/termux-app/blob/8e3a8980a849046adbd4156741e1d84047ee1df6/terminal-emulator/src/main/java/com/termux/terminal/TerminalEmulator.java#L1978 [st-src-2]: https://git.suckless.org/st/file/st.c.html#l1860 <!-- st source code hint: look for the function osc_color_response --> [conhost-src]: https://github.com/microsoft/terminal/blob/d2bd18735edfcf51046fadba14f85b5cf78d7112/src/types/utils.cpp#L161 [vte-src]: https://gitlab.gnome.org/GNOME/vte/-/blob/86074ccede977bf2a594b781821c4a80c0343872/src/vtetypes.cc#L48 [vte-src-2]: https://gitlab.gnome.org/GNOME/vte/-/blob/86074ccede977bf2a594b781821c4a80c0343872/src/vteseq.cc#L1388 What do you think?
bash reopened this issue 2024-03-19 14:04:04 -07:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
master
main
devs/simotek/colorschemes
terminology-1.9
devs/bu5hm4n/fix-for-billiob
terminology-1.8
terminology-1.7
terminology-1.6
terminology-1.5
terminology-1.3
terminology-1.2
terminology-1.4
terminology-1.1
devs/iscaro/meson
devs/bu5hm4n/cwd_fix
devs/discomfitor/focus
devs/bu5hm4n/next
devs/jayji/fixes
devs/discomfitor/teamwork
devs/zehortigoza/user-title
terminology-0.9
devs/discomfitor/cc
terminology-0.5
devs/cedric/ssh
devs/stefan/coverity-fixes
devs/discomfitor/demos
devs/lucas/wip
v1.13.0
Labels
Clear labels
No items
No Label
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: enlightenment/terminology#14
No description provided.
Delete Branch "%!s(<nil>)"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?