
Design, edit and share custom terminal color schemes - rohan1024
https://terminal.sexy/
======
hnlmorg
A note to any developers writing console applications, please please _please_
don't use RGB values in your terminal colour -- only use the 8 base colours
plus highlight. RGB values prevent your users terminal from using the custom
colour palettes your users might define (and like this site helps you to
create). Aside from being a little annoying, it can cause genuine usability
problems for some groups of people who use custom palettes:

\- for visual impairment reasons (eg high contrast colours)

\- or to differentiate different servers (eg different background colours for
dev or prod servers)

\- or have less contrasting colours to reduce eye strain (eg the Solarized
colour schemes)

\- might suffer from colour blindness so pick colours that contrast better
with their condition

\- or even just those that prefer a white or other non-black backgrounds for
readability reasons (eg they might be dyslexic and find a non-black background
or different shades of text easier to read).

I do fall into two of those categories and run into this issue a lot since
there is a trend these days for developers to hard code colour values into
their applications.

Equally, some developers use the "you can select a custom colour map - I just
define a pretty default" argument and while that's slightly better, the best
option would be still to default to the standard 8 colours (or the default
unformatted text) and let users _opt into_ RGB values if they wish. This will
save your users from constantly having to define the same colour palettes in
every application.

~~~
JdeBP
As I noted at
[https://news.ycombinator.com/item?id=22002036](https://news.ycombinator.com/item?id=22002036)
. (-:

It has been really 16 colours since the days of AIXTerm, even though that did
not get formally standardized. Only a couple of places nowadays make the error
of conflating bold and bright. It's not really "8 base colours plus highlight"
at all, and that's certainly not the case with the tool at hand.

You are also approaching being a decade late with a plea not to use direct RGB
colour.
[https://gist.github.com/XVilka/8346728](https://gist.github.com/XVilka/8346728)
started in 2014, for example.

What the tool at hand really tells us is that there are already at least 18
different ways of specifying a colour palette. Perhaps the better idea
nowadays is to promote a common 16-colour-to-RGB palette mechanism for TUI
applications, akin to mailcap or something.

~~~
a1369209993
We _have_ a common 16-color-to-RGB mechanism: write \e[34m or similar and let
the terminal do its damn job.

~~~
JdeBP
No, you do not have that. For starters, it's still a matter of debate whether
the world is wholly ECMA-48:1976 yet. There are people who contend that we
cannot assume universal adherence to a 1976 standard.

* [https://unix.stackexchange.com/q/548158/5132](https://unix.stackexchange.com/q/548158/5132)

* [https://unix.stackexchange.com/a/5802/5132](https://unix.stackexchange.com/a/5802/5132)

Then there's the matter that only colours 0 to 7 are in fact standardized in
ECMA-48. That's 8 colours, not 16. The AIXTerm mechanism has never been
standardized, and what _has been_ standardized in the likes of ITU T.416 is
both not the AIXTerm mechanism _and_ badly implemented to the extent that
people are still today pushing for two long-standing mistakes to be corrected
by software authors.

Moreover, not every terminal agrees on how to interpret even the non-T.416 SGR
control sequences. Famous and _still widely used_ terminal emulators, such as
the Linux built-in one for its KVTs, respond to boldface (SGR 1) by changing
colour; in contrast to many terminal emulators where _boldface means boldface_
and isn't a colour change. The control sequences are _not the same_ and cannot
be hardwired.

* [https://unix.stackexchange.com/a/608930/5132](https://unix.stackexchange.com/a/608930/5132)

Personally, I am of the opinion that one can nowadays assume ECMA-48:1976 at
minimum as long as one allows for "dumb" _as well_. But that doesn't mean
further assuming the AIXTerm 16-colour mechanism. Until you go and change the
Linux KVT's (and others') handling of boldface, and then the "linux-16color"
entries in termcap and terminfo, to actually match your claim, your claim will
remain incorrect.

(Also note the caveats at
[https://news.ycombinator.com/item?id=23752827](https://news.ycombinator.com/item?id=23752827)
.)

Then there's the fact that a decent common TUI palette system wouldn't be
16-colour-to-RGB, because that would still need a second map. It would be
better than that. That's just a barebones concept. It would be display-
element-to-RGB, learning from the design of GUI palettes back in the 1980s,
where the colour schemes specified colours for abstract UI elements such as
"window title", "pressed button", "file", "directory", "text label", and the
like. And indeed from the design of Borland TurboVision, which did the same.

------
gregsadetsky
Congrats! Very small note: when changing any of the colors, the URL changes
presumably to reflect the new state.

The issue is that these "stateful" URLs don't work when accessed directly. Try
this one that I got by fiddling with the colors a bit:

[https://terminal.sexy/#HR8hxcjGKCoupUJCjJRA3pNfX4GdhWePXo2Hc...](https://terminal.sexy/#HR8hxcjGKCoupUJCjJRA3pNfX4GdhWePXo2HcHiAXXyqzGZmtb1ogWo-
gaK-spS7ir63xcjG)

The site hangs and does not initialize.

Cheers

(I just emailed the site's author about it being discussed here as well)

------
megous
You can also do this for Linux kernel console, if you implement export for
vt.default_{red,grn,blu} kernel command line parameters.

[https://elixir.bootlin.com/linux/latest/source/Documentation...](https://elixir.bootlin.com/linux/latest/source/Documentation/admin-
guide/kernel-parameters.txt#L5584)

That would be very useful :)

Or this:

[https://github.com/EvanPurkhiser/linux-vt-
setcolors](https://github.com/EvanPurkhiser/linux-vt-setcolors)

------
shiftpgdn
Vaguely off topic but has anyone encountered a person using the "grass" or
"ocean" OSX terminal themes in the wild? Why are they even there?

~~~
hnlmorg
Not in macOS Terminal specifically but one of my colleagues in a previous job
used similar themes to differentiate between different servers. Database
servers would be one theme, dev web servers another, and prod web servers a
3rd theme. It was a system that worked well for him but not something I've
felt compelled to emulate.

~~~
css
I do this with git repos: backend repo code editor and associated ttys share
one theme, frontend another, and so on. Makes it very easy to know the context
of what I am working with at a glance.

------
jaquers
Really well done application with tons of export / import formats, lots of
presets and the palette is integrated into the UI - delightful.

Thanks for the submission.

~~~
kergonath
Indeed. And a great use of the .sexy TLD.

~~~
cptnapalm
Sadly, it triggers my work's block filter.

