[Tickit-dev] How to handle RGB8 ("24bit") colours

[Paul "LeoNerd" Evans]

There's a blueprint scheduled for the current development cycle for the
v0.2 release, on the subject of supporting RGB8 (otherwise known as
24-bit, or truecolour) colour codes:

  https://blueprints.launchpad.net/libtickit/+spec/rgb8

This asks the questions:

  * On the (frankly, likely) chance that it isn't [supported by the
    terminal], how to handle this? Should the library try to translate
    to "nearest 256", like it downsamples 256 to 16 or 8-colour
    palettes?

  * What happens if you set a pen colour using either RGB8 or xterm256
    models and then try to query its value via the other?

I don't really have any clear answers to these questions. What does
anyone feel about it?

One possible solution I have is to basically say "it's the user's
problem", and they shouldn't be using RGB8 colours if the terminal
doesn't support it. But then, how do they know that?

Architecturally, it's easy enough for the TickitTerm instance to ask
its actual terminal whether RGB8 is supported, but that doesn't really
help the user code directly. Given the window+renderbuffer way that
most code would be working, nobody is really touching the terminal
instance directly any more. That all happens implicitly in the lower
layers of the root window management.

The primary way that user code deals with a colour is via a pen
instance, but those are abstract stores of key/value pairs basically,
and don't directly know anything about the terminal they might render
onto (the same limitations would also apply, incidentally, to italics or
strikethrough attributes for example). Additionally, a renderbuffer
also can't know about what is supported, for the same reason.

One possible thought is that a window can know, because every window is
part of a hierarchy built up from the root window of a particular
terminal, and that is associated with a given term instance, so it
would be possible for a window to enquire abilities of its backing
terminal. Perhaps this is a possibility, to add some sort of "Can the
terminal do X?" query method on window instances. While we're at it we
can add queries for any of the other rendering attributes or whatever
else seems appropriate as well.

This solution seems to answer both questions easily enough. A
TickitTerm shouldn't have to do anything special when asked to switch
to an RGB8 colour when the underlying terminal doesn't support it,
because "you shouldn't do that". Since the application knows it's
working with RGB8 colours directly, it wouldn't have to bother with any
kind of translations between the two - set RGB8 then query with index
can return some rogue value like -1, and similar in the opposite
direction. The two should be considered mutually-exclusive attributes
in a pen; when one is set the other gets cleared.

Does this feel like the right direction to be going in? What does
anyone else think here?

-- 
Paul "LeoNerd" Evans

leonerd at leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://mail.leonerd.org.uk/pipermail/tickit-dev/attachments/20171115/083c675a/attachment.sig>