GNOME Bugzilla – Bug 781369
Cursor color resets to default if foreground/background/palette colors changed
Last modified: 2021-06-10 15:20:45 UTC
In VTE, if you set the cursor color and then set a foreground, background or palette color afterwards the cursor color resets to the default. This bug does not affect gnome-terminal or xfce4-terminal because they update all of the colors whenever there is any color change whereas in Tilix I only update the specific colors that changed. Changing other colors such as highlight or bold does not cause the issue.
Yup. It's done in VteTerminalPrivate::set_colors() in the last 4 branches of the switch statement, setting the corresponding "unset" variable and finally resetting in the reset_color() call. I guess (haven't tried) the fix is as simple as wiping out these bits. I have no idea why it's done this way. Probably a legacy leftover. Christian, do you have any idea about the intent? Any risk of breaking something with this change?
I think the intent in ::set_colors() was that setting fg+bg+palette will make all the other colours be derived from these (which for bold is a mix, and cursor and highlight fg/bg at NULL meaning a reverse effect). (And on init to initialise the colours with that). Using the individual colour setters vte_terminal_set_color_*() with NULL has the same resetting effect. Not sure if I should call this a documentation bug or if we should change the way the API works? (In reply to Gerald Nunn from comment #0) > Changing other colors such as highlight or bold does not cause the issue. Hmm the code does the same for cursor bfg/bg as for highlight fg/bg...
By highlight and bold, I meant that changing them does not reset the cursor color to the default. However, by your comment I guess you are implying that all three of these (highlight, bold and cursor) will change if the fg, bg or palette is changed? Ideally I would think the API should be updated so that cursor, bold and highlight are only changed on fg, bg or palette changes if the colors are using the default state. This means though that the VTE would have to track this default state. A documentation only change would work and I can adjust the tilix code to handle this. However, some UI elements like adjusting the transparency slider can result in a lot of BG changes happening in the VTE. Setting all colors in response to this is somewhat inefficient but I don't think deal breaking.
(In reply to Christian Persch from comment #2) > which for bold is a mix, > and cursor and highlight fg/bg at NULL meaning a reverse effect Not sure about bold (should double check) but for the others the NULLness should be preserved, and applied runtime. I guess this was mostly fixed with the separation of API and escape-sequence colors (vte-0.35-ish, bug 705985). > Not sure if I should call this a documentation > bug or if we should change the way the API works? I vote for the latter since the current behavior doesn't make too much sense for me. (In reply to Gerald Nunn from comment #3) > Ideally I would think the API should be updated so that cursor, bold and > highlight are only changed on fg, bg or palette changes if the colors are > using the default state. Fully agree. > This means though that the VTE would have to track > this default state. Which it does, if I remember correctly.
This bug also seems to effect sakura: https://bugs.launchpad.net/sakura/+bug/1697522
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vte/-/issues/2392.