After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 678765 - vte_terminal_set_colors ignores dim colors
vte_terminal_set_colors ignores dim colors
Status: RESOLVED FIXED
Product: vte
Classification: Core
Component: general
0.32.x
Other All
: Normal normal
: ---
Assigned To: VTE Maintainers
VTE Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-06-25 08:58 UTC by Daniel Micay
Modified: 2015-01-17 11:44 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
an example to demonstrate the bug (see comment header in source) (1.35 KB, text/plain)
2012-06-25 08:58 UTC, Daniel Micay
Details

Description Daniel Micay 2012-06-25 08:58:27 UTC
Created attachment 217174 [details]
an example to demonstrate the bug (see comment header in source)

After setting the terminal colors with a palette_size of 24 using vte_terminal_set_colors(), the dim colors are not set to the colors given in the palette.

A small example program is attached which attempts to set all the dim colors to black, but they still appear as dimmer versions of the other colors.
Comment 1 Daniel Micay 2012-06-25 19:00:02 UTC
It looks like this could just be a documentation issue rather than a bug in the code. A palette of size 24 doesn't seem to have any significance (they don't seem to actually be the dim colors, as the docs imply).

This is used in the code to determine where to get the dim colors:

/* Indexes in the "palette" color array for the dim colors.
 * Only the first %VTE_LEGACY_COLOR_SET_SIZE colors have dim versions.  */
static const guchar corresponding_dim_index[] = {16,88,28,100,18,90,30,102};

In the vte_terminal_set_colors function, a palette of size 24 doesn't seem to have any special handling compared to one between size 25 and 255 (so there doesn't seem to be a reason to not allow a size of [17..23]).
Comment 2 Egmont Koblinger 2014-08-22 20:27:01 UTC
See also bug 735245.  After addressing that, this will indeed be a documentation issue only.
Comment 3 Egmont Koblinger 2014-08-22 21:20:14 UTC
Well, it's more complicated...

"If @palette_size is 8 or 16, the third (dim) and possibly the second (bold)
8-color palettes are extrapolated from the new background color and the items
in @palette." -- this is not true for bold [which really should be called "bright" here] colors, they are reverted to their hardwired defaults if only 8 colors are supplied.

Any colors that are beyond the supplied palette are reverted to their builtin defaults -- not a single word about this in the doc.

Special colors that are set via other API calls (bold, highlight, cursor colors) are also reverted -- again not documented and unexpected.

A loop that for each index fills it with the default value and then overrides with the specified value just looks silly to me :)

I wouldn't allow any palette size between 16 and 256, it just doesn't make sense to supply a partial palette (maybe 232 could be allowed).
Comment 4 Egmont Koblinger 2015-01-17 11:44:53 UTC
Was fixed in bug 735245 and bug 446533.