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 768850 - First palette entry is inconsistent
First palette entry is inconsistent
Status: RESOLVED FIXED
Product: gnome-terminal
Classification: Core
Component: Profiles
3.20.x
Other Linux
: Normal normal
: ---
Assigned To: GNOME Terminal Maintainers
GNOME Terminal Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-07-15 16:09 UTC by Tony Houghton
Modified: 2016-07-22 14:44 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Fix (1.12 KB, patch)
2016-07-20 10:12 UTC, Egmont Koblinger
committed Details | Review

Description Tony Houghton 2016-07-15 16:09:55 UTC
There seems to be a bit of a problem with the first palette entry (numbered 1 in the profile dialog). After choosing a theme the button appears mid-grey, but the corresponding colour in terminals is black, and if I open the colour picker dialogue the value shows as #000000. I can edit the colour OK, but if I switch theme then back to my Custom theme it goes black again.

After editing this colour the button initially shows my chosen colour, but on changing theme it shows black. If I close the profile dialog and reopen it, it goes back to mid-grey.

I think all the other palette entries are working correctly.

I would guess there's a for loop in the code which starts from 1, but internally the numbering should start from 0.
Comment 1 Egmont Koblinger 2016-07-20 08:13:47 UTC
Yup it's indeed quite weird. When I open the profile prefs it's white. Upon toggling between linux, xterm, urxvt and tango it remains white. Choosing Solarized selects the proper solarized color, and then choosing linux or xterm or similar makes it black as desired. Wtf?? :)
Comment 2 Egmont Koblinger 2016-07-20 10:08:49 UTC
In profile-editor.c profile_palette_notify_colorpickers_cb() removing the if (!rgba_equal (...)) condition (just the condition itself; keeping the body) fixes the problem. I think there's some implicit uninitialized default which happens to be white on the UI but black in the underlying data structure.

Shall we remove that condition, or initialize consistently? :)
Comment 3 Egmont Koblinger 2016-07-20 10:12:26 UTC
Created attachment 331810 [details] [review]
Fix
Comment 4 Christian Persch 2016-07-21 16:50:43 UTC
Comment on attachment 331810 [details] [review]
Fix

Thanks! master, and at your option, 3-20 too.
Comment 5 Egmont Koblinger 2016-07-22 14:44:30 UTC
Review of attachment 331810 [details] [review]:

Committed to master & 3-20.