GNOME Bugzilla – Bug 605754
For gnome-terminal colors use the defined default profile instead of assuming the profile 'Default'
Last modified: 2014-10-24 20:49:54 UTC
Created attachment 150588 [details] [review] Use default_profile from gnome-terminal colors Running against HEAD. One of my biggest issues with hotssh has been the default color scheme. I got new monitors yesterday and finally got fed up with the beige/yellow background and started digging in the code. I found in vteterm.py that the call was to read the gnome-terminal profile 'Default' instead of checking the default_profile entry under global and reading its settings. I created a quick 2 line patch that does the check first, and it works fine. I still don't know why the default profile was beige/yellow though, the 'Default' on my box is a white background. That might be a separate issue.
Created attachment 151067 [details] [review] Full gnome color palette from active default profile
So... I've played with this a bit more after realizing it only set fore/backgroun colors. What I'm not sure with my new playing is what the "proper" fix would be, because I'm not sure what all the scenarios and behavior surrounding the "palette" entry in gconf is. Part of me is inclined to think the palette should always be there, but that would be an assumption. I did a simple check, and this patch covers the situation where the palette key has nothing in it. It blows up if the key isn't there, but the same would occur with background and foreground keys. So anyway, I'm attaching a newer patch that implements the active profile + its full palette.
Thanks for the patch, Greg! It didn't apply to git master, and had a few issues: * We need to monitor the profile key for changes * Some duplication between set_color and set_colors etc. I cleaned this up and committed.