[Konsole-devel] [konsole] [Bug 344181] konsole 256 color support differs from xterm/rxvt

[Egmont Koblinger]

https://bugs.kde.org/show_bug.cgi?id=344181

--- Comment #5 from Egmont Koblinger <egmont at gmail.com> ---
Dunno, I'm not konsole's developer.

My 2 cents:

This whole palette approach is braindamaged and broken on so many levels...

It was probably 1997 when I replaced my 1MB video card (which allowed me either
16 bits per pixel (5+6+5 per color) @800x600, or palette-based 8 bit per pixel
@1024x768 (the palette always being adjusted to the active window, the rest
looking totally broken) by a 2MB card that allowed 16 bits @1024x768. Since
they I'm grateful I never had to look back to palette mode.

In case of terminals:

Your app can try to query or modify the palette – you can't be sure if it'll
work, it depends on the terminal. Moreover, querying the palette is an
asynchronous operation, you'll get a response later, and e.g. if you work over
ssh, you can't be sure what that "later" means. If you have a timeout, you're
already prone to race condition. Okay, you can issue the querying and then the
setting escape sequences, and see later whether you happen to get a response.
Cumbersome to implement, and I don't know if any library (e.g. ncurses) helps
you here or if there's any app actually doing this. Querying is of course
necessary to be able to restore the palette when the app quits. Still it will
be left in modified state if your app crashes (but then other properties of the
terminal are not restored either, so it'd not that bad).

Palette approach doesn't allow an app to use any color that it wants to (as
e.g. directed by an external source, e.g. html viewer that wants to show you
the page in its actual colors), see also
https://www.midnight-commander.org/ticket/1849.

Palette approach can't work in terminal multiplexers with side-by-side windows
(e.g. tmux), unless you're willing to see faulty colors in the non-active
screens (as I did with my desktop 18 years ago) or unless the multiplexer
translates the palette colors into direct RGB when it talks to the underlying
actual terminal emulator (in which case users would complain that it ignores
their terminal emulator's color settings).

Palette approach mangles the look of the scrollback buffer, so ideally it's
only useful for fullscreen apps that switch to the alternate screen where
there's no scrollback buffer. Some terminal emulators still allow you to access
the normal screen's scrollback when you're on the alternate screen, though, so
it'd still look broken there.

Many people claim that direct RGB is an overkill and who needs 16M colors at
the same time anyway?  My desktop monitor can't even show 16M colors at the
same time either. They miss the point that it's not about showing this many
colors at once; it's about showing any of the colors at any time, without
independently from the rest of the screen. They also miss the point that colors
of the 256-color palette are still way too far from each other.

IMO, ideally, every graphical terminal emulator would implement true color
support, and every app would allow you to use these colors directly (in
addition to keeping the 8/16/256 legacy palette colors). Unfortunately there's
a huge resistance in implementing this feature from authors of many terminal
emulators, and from the authors of the two most popular screen drawing
libraries: ncurses and slang. Actually, these libraries internally also think
in terms of palette (what a shame) and would have to be significantly
redesigned/extended to support RGB (see e.g.
https://www.midnight-commander.org/ticket/3264). I'm personally quite
disappointed to see that even 20-ish years after desktops switched from palette
to RGB, many people still think it's an overkill in terminals and wish to get
stuck in the ancient historical world.

Here's a great summary of the state of true color support; I've no clue how
up-to-date it is: https://gist.github.com/XVilka/8346728. Anton (the maintainer
of that page) and me tried to push for this feature about a year ago, but we
seemed to hit a wall. The feature didn't reach the critical support to become
mainstream, and unfortunately seems to remain an extra which is randomly
supported by some scattered terminals/apps.

In an ideal world, your terminal emulator would support 16M true colors (it
does since you use konsole which supports it) and so would your app (I'm afraid
it doesn't yet, but maybe will one day) and you'd configure your app to use
these. The it could use base16 (or whatever) without ever mangling the palette.

-- 
You are receiving this mail because:
You are the assignee for the bug.