Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hex colors #3494

Open
wants to merge 9 commits into
base: main
Choose a base branch
from
Open

Hex colors #3494

wants to merge 9 commits into from

Conversation

michaelfaith84
Copy link
Contributor

Brief overview of PR changes/additions

Added support for truecolor in the portal (xterm truecolor) and the web portal using the style attribute. Syntax used is |#0f0, |#0f0f764, |[#00f, etc.

Motivation for adding to Evennia

#3248 Who doesn't like more colors?

Copy link
Member

@Griatch Griatch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I can tell (haven't tested this yet), this looks like a cool implementation.

  • I have a few inline comments, check them out
  • We don't really have a way to test this actually works. It sounds like the color ansi|xterm default command should be extended to able to do color truecolor for supported clients and have it show a suitable range of colors (clearly showing all colors is not possible). It is also a good way to show that it gracefully maps to xterm256 (or even to ANSI) properly.

Comment on lines +150 to +158
# use name to identify support for xterm truecolor
truecolor = False
if (clientname.endswith("-TRUECOLOR") or
clientname in (
"AXMUD",
"TINTIN"
)):
truecolor = True

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The TTYPE/MTTS protocol supports TRUECOLOR as a valid parameter. With this check it seems you are assuming truecolor=False and ignoring the TTYPE/MTTS value sent by the client completely.

I think you should honor the handshake and only override if there is no such value in the communication, or if you know that the given client sends a faulty value (or don't support the proper handshake, which is what most of these client-exceptions are for).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gotcha. I was just following the example set in the case above for xterm256. Thanks for the correction.

Edit: Actually, looking at the code, it appears that happens in the following step? Which I suspect is why xterm256 is handled in the same way. But please let me know if I'm misunderstanding it.

if cachekey in _PARSE_CACHE:
return _PARSE_CACHE[cachekey]

# pre-convert bright colors to xterm256 color tags
string = self.brightbg_sub.sub(self.sub_brightbg, string)

def do_truecolor(part: re.Match, truecolor=truecolor):
hex2truecolor = HexColors()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why initialize this every regex query? It seems needlessly expensive. It's a stateless class, it could be initialized once at the top of this module.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤦‍♂️ Mistake on my part! Sorry.

"""
Parses a string, subbing color codes as needed.

Args:
truecolor:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing docstring here.

prop += f'"'
return prop

def _split_hex_to_bytes(self, tag: str) -> tuple[str, str, str]:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor style-nitpick: Place the methods being used before the methods using them. This is standard across Evennia. So move these private methods up towards the top of this class.

@@ -8,7 +8,9 @@

from django.test import TestCase

from evennia.utils.ansi import ANSIString as AN
from evennia.utils.ansi import ANSIString as AN, ANSIParser
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not ANSI though, it's Truecolor. I think this belongs in its own test module utils/tests/test_hex_colors.py.

@@ -52,3 +54,124 @@ def test_split_with_mixed_strings(self):
self.assertEqual(split2, split3, "Split 2 and 3 differ")
self.assertEqual(split1, split2, "Split 1 and 2 differ")
self.assertEqual(split1, split3, "Split 1 and 3 differ")

# TODO: Better greyscale testing
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok.

Comment on lines 370 to 372
# Classes can't be used for true color
prefix = (f'<span '
f'class="{" ".join(classes)}" '
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You comment that classes cannot be used, yet the class= is set here? At the very least the comment is confusing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry about that! Classes can't be used for (for all) colors because of the verbosity of truecolor BUT other classes can still be applied (for things like blink, etc). I will clarify the comment.

-Reordered methods in HexColors
-Separated truecolor tests
-Clarified comment re: classes and styles in text2html.py
-Changed ansi.py to only instatiate HexColors once 🤦‍♂️
-Fixed missing docsctring in parse_ansi re: truecolor
@michaelfaith84
Copy link
Contributor Author

As far as I can tell (haven't tested this yet), this looks like a cool implementation.

Thanks! I was worried because it was a different method of implementation than Evennia was using but it seemed like a good choice given @InspectorCaracal's project in #3253.

* We don't really have a way to test this actually works. It sounds like the `color ansi|xterm` default command should be extended to able to do `color truecolor` for supported clients and have it show a suitable range of colors (clearly showing all colors is not possible). It is also a good way to show that it gracefully maps to xterm256 (or even to ANSI) properly.

I hadn't noticed that command. Thanks for pointing it out!

…e because of the number of colors it supports (style borrowed from the termstandard repo's test)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants