GNOME Bugzilla – Bug 692753
gnome-terminal opacity always resets to zero
Last modified: 2013-02-07 23:24:00 UTC
I just installed Fedora 18 and gnome-terminal background, when set to transparent, always resets to zero opacity when the first terminal is opened (it opens completely transparent). The first terminal I open after boot appears completely transparent. If I configure its opacity to be non-zero, all subsequent terminals comply to this configuration. However, if I close all terminals, the next one I open resets opacity to zero again. This happens to all profiles. gnome-terminal version is 3.6.1
Looks like a gconf bug to me; there's no code writing to the opacity gconf key when creating a new terminal. In any way, this setting has been removed from 3.7, so this bug is OBSOLETE for gnome-terminal.
Hi Christian, I'm not sure the problem is when a new terminal is created, it seems the setting simply isn't being stored anywhere and is being kept only in memory. If I change profile "P" and set its transparency to 50%, all windows with the same profile are affected immediately, but if close all of them and open a new "P" window, it is completely transparent. At any time (regardless of windows being opened or not), if I check apps.gnome-terminal.profiles.P.background_darkness with gconf-editor, it is always 0.0. Also, even though this setting won't exist anymore on GNOME 3.7, IMO it should deserve some attention for 3.6 since it just came out on Fedora 18, which is known to be "bleeding edge"; other distros will soon follow, and it will be a while (at least 6 months) before Fedora 19 comes out with GNOME 3.7 (or 3.8).
That's why I say it looks like a gconf problem. When you change the value from inside g-t via its prefs dialogue, the new value is cached in libgconf2 and from then on all reads use that cached value; but it looks like the new value isn't sent to the gconf demon nor read from it correctly. The only thing I could do to fix this in 3.6.x is remove transparency support there too; I'm not inclined to debug this obsolete feature any, esp since it's not a g-t bug.
Thks for the explanation. Indeed, removing transparency from 3.6 would make things worse. Since it's not a g-t bug, do you have any advice on which product/component I should file this bug then? Platform > glib > gsettings? I really don't want to spend the next 6 months resetting the transparency manually every time I login ;-) Also, just out of curiosity, the setting has been removed from 3.7, but g-t will still be able to be translucent, right?
3.6 doesn't use gsettings. AFAICT it's a gconf bug (not the first one that g-t exposes), but since gconf itself is unmaintained, I don't think filing it will matter. Just to be clear, if you set g-t up *not* to be transparent, does that setting stick? For your last question, see https://live.gnome.org/Terminal/FAQ .
I did some additional testing, and found some other (weird) info: I have configured alt+t to open a new terminal with the default profile using this command: "gnome-terminal --geometry=80x40". If I use this key combo to open a terminal, it resets opacity to zero if there are no other windows opened. BUT if I run the *exact same command* by typing it on alt+F2 prompt, opacity setting IS honored as long as I haven't reset it doing what I described on the previous paragraph. To make it clearer: SCENARIO #1 (no windows opened): 1. press alt+t >>> opacity setting is RESET TO ZERO 2. configure opacity to be non-zero 3. press alt+t again >>> opacity setting is HONORED 4. close all windows 5. press alt+t >>> back to step #1 SCENARIO #2 (no windows opened): 1. press alt+t >>> opacity setting is RESET TO ZERO 2. configure opacity to be non-zero 3. close all windows 4. run "gnome-terminal --geometry=80x40" (the *same command* bound to alt+t) using alt+F2 >>> opacity setting is HONORED 5. close all windows 6. press alt+t >>> back to step #1 Scenario #2 holds true even between logins -- as long as I don't perform steps #5 and #6 sequentially. So, AFAICS, running the same commands through a keyboard shortcut has some weird side-effect not present if they are run through alt+F2. This makes no sense at all to me, but I retested a couple of times to make sure I wasn't missing anything. I hope you guys are able to reproduce it with the info I gave above. If you need additional info, please let me know. BTW: thks for the pointer for 3.7 g-t FAQ. As an end user it seems a little too cumbersome having to resort to Devils Pie (which I already use for other purposes) to set terminal transparency, but I'm sure you guys have good reasons for that, so I won't jump to conclusions. And, yes, please make sure you provide more detailed instructions on how to do that ;-)
So this points to a problem with env vars, most likely the 'launch by global keybinding' method is not setting up some env var that gconf needs.
Nice, it seems we're getting somewhere. What's the component responsible for the "launch by global keybinding" method so that I can file a bug report?
I think it's gnome-settings-demon. You could make a script that just writes the environmen to a file, and bind that to the keybinding / launch it from run dialogue, and compare the output, to see if this is really what happens.
Good idea. I just did it and the resulting diff is: ~ diff keybind altf2 4d3 < DESKTOP_AUTOSTART_ID=10ee44445250437bb6135974084547510200000269310001 8a8,9 > GJS_DEBUG_OUTPUT=stderr > GJS_DEBUG_TOPICS=JS ERROR;JS LOG 22a24,27 > LC_MEASUREMENT=pt_BR.utf8 > LC_MONETARY=pt_BR.utf8 > LC_NUMERIC=pt_BR.utf8 > LC_TIME=pt_BR.utf8 31c36 < QT_IM_MODULE=xim --- > QT_IM_MODULE=ibus 51c56 < XMODIFIERS=@im=none --- > XMODIFIERS=@im=ibus Do you see anything there that could be the cause?
Well those differences in the input method settings shouldn't be there, but that's a separate bug (which I guess should be filed too). LC_NUMERIC might make a difference.
Makes sense, since the opacity is stored internally as a double between 0.0 and 1.0. I was going to file the bug on gnome-settings-daemon, but I'm not sure which component to associate it to (there's a "keybindings" component which is marked as obsolete). Any tips on which one to use?
I finally filed bug 693381 for gnome-settings-daemon, let's see how it goes.
*** Bug 693375 has been marked as a duplicate of this bug. ***