When a running app changes the color scheme, after losing focus the scheme is reset (and ruined).

Bug #1512905 reported by Brendan
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Terminator
Fix Released
Low
Stephen Boddy

Bug Description

I have a Vim plugin that, when Vim is started, changes the current color scheme of the terminal to (almost) exactly match the colors that would have been displayed had Vim started in a gui (ie true color). This works flawlessly in other terminal emulators, such as gnome-terminal and xfce4-terminal (although doesn't work at all in kde konsole), so I know it's very much possible for it to work. However, in Terminator, the color scheme is successfully set by Vim initially, but anytime Terminator either loses focus or is re-sized, the colors reset and the result is not only hideous but absolutely unreadable. The only way to fix it is to kill Vim and restart it.

I tried to get a screenshot but that proved impossible, whenever I took the screenshot, Terminator lost focus and the colors were reset. So I just took one of Terminator exhibiting its broken colors beside Xfce4-Terminal showing what it ought to look like (and did, before taking the screenshot).

Obviously this isn't a huge bug, but it's enough that Terminator is practically useless to me.

Screenshot: http://i.imgur.com/PMENzWP.jpg

Extras:

Running: Ubuntu 15.10, bug appeared in both Xfce4 and in Plasma
Version: 0.97

I've attached a debug log in which it seems clear that the problem occurs because Terminator reapplies all the default settings for color when it has lost focus, which makes sense.

The vim plugin, incidently, is called CSExact, link below.

https://github.com/KevinGoodsell/vim-csexact

Revision history for this message
Brendan (brendan-leason-4) wrote :
Revision history for this message
Stephen Boddy (stephen-j-boddy) wrote :

So the focus out/in events for the terminal widget switch between active and inactive colour palettes. The inactive one is generated from the configured active palette multiplied by the amount configured in the prefs.

A quick check of the VTE docs suggests that while we can *set* the palette, there is no obvious way to *get* the current palette. I see from the plugin code that it looks to be using shell escape codes to reconfigure the palette. It may be possible to detect those from outside the VTE widget, but if it is, I'm not aware of how to do it.

A fudge solution (if you can live without the dimming of unfocused terminals) is to add a simple wrapping clause around the palette modifications in the focus in/out handlers (terminatorlib/terminal.py, on_vte_focus_in & on_vte_focus_out).

You can test this out by editing terminatorlib/terminal.py, on_vte_focus_in & on_vte_focus_out methods to something like:

if self.config['inactive_color_offset'] < 1.0:
    self.vte.set_colors(self.fgcolor_active, self.bgcolor,
                            self.palette_active)

You might need to indent the following set_cursor_color call too.

So now, if you set the "Unfocused terminal font brightness" in Global prefs to 1.0, the palette mods don't happen at all and your vim plugin palette should be left alone.

Changed in terminator:
status: New → Incomplete
importance: Undecided → Low
Revision history for this message
Brendan (brendan-leason-4) wrote :

That solution seems to have worked. I had the dimming effect disabled anyway, so this is no problem.

Assuming something else doesn't go wrong (I don't see why anything would), I can now permanently retire all the other terminal emulators I had installed. Thanks for the help.

Changed in terminator:
status: Incomplete → Triaged
assignee: nobody → Stephen Boddy (stephen-j-boddy)
Revision history for this message
Stephen Boddy (stephen-j-boddy) wrote :

Hey Brendan, I was having a quick dig through the VTE bugzilla to possibly request an API call to query the current palette. What I found while checking was:
https://bugzilla.gnome.org/show_bug.cgi?id=705985#c9

It looks like the GTK3 branch would would even with the dimming. Any chance you can test the GTK3 branch?

Revision history for this message
Brendan (brendan-leason-4) wrote :

I tried to give that a go, but I just cannot seem to get that version of terminator to run. I tried building and running a local build of it, and got an import error. I triple checked that I had all the necessary python libraries, and definitely do. I tried installing it to a directory in ~/local, and got an import error. I banged my head on a concrete wall a few times and decided to just let it install to wherever it wanted to, overwriting the original copy if need be. It installed to /usr/local/ instead, and when running it I got an import error. I tried copying all of the python libraries from /usr/lib/ to /usr/local/lib/, and got an import error.

Traceback (most recent call last):
  File "/usr/local/bin/terminator", line 112, in <module>
    TERMINATOR.create_layout(OPTIONS.layout)
  File "/usr/local/lib/python2.7/dist-packages/terminatorlib/terminator.py", line 279, in create_layout
    window, terminal = self.new_window()
  File "/usr/local/lib/python2.7/dist-packages/terminatorlib/terminator.py", line 205, in new_window
    window = maker.make('Window')
  File "/usr/local/lib/python2.7/dist-packages/terminatorlib/factory.py", line 94, in make
    output = func(**kwargs)
  File "/usr/local/lib/python2.7/dist-packages/terminatorlib/factory.py", line 100, in make_window
    import window
  File "/usr/local/lib/python2.7/dist-packages/terminatorlib/window.py", line 12, in <module>
    from gi.repository import Keybinder
ImportError: cannot import name Keybinder

It doesn't make sense. I know I have python-vte and python-keybinder installed. I'm sure I'm missing something here.

Revision history for this message
Stephen Boddy (stephen-j-boddy) wrote :

Ah yes, I think what you're missing is the GObject Instrospected version of Keybinder. You're on the latest Ubuntu, so it should be available in your repositories. Try:
# apt-get install libkeybinder-3.0-0 gir1.2-keybinder-3.0

That should install the newer GI library, and the import will stop throwing the exception.

Revision history for this message
Brendan (brendan-leason-4) wrote :

Thanks, that's gotten it working. Took me forever to clear out the /usr/local/lib folder back to the way it was before I just copied everything there though.

The problem does seem to be gone in this version, more or less. When vim is on and in the foreground, the window does not dim when losing focus and thus doesn't mess with the colours. When Vim is not active, it dims as expected. I don't like the dimming in any case, but if I had wanted to use it, from my limited testing, it seems it would be functional anytime I'm not using Vim.

Revision history for this message
Stephen Boddy (stephen-j-boddy) wrote :

Yeah, so what the vte widget is doing is essentially maintaining two palettes. The one set programatically by Terminator, and one set by bash escape codes/scripts/programs.

The second one takes priority, and Terminator only ever updates the first one. So the Terminator dimming code only updates the first palette, and has no effect when the second palette is being used. Once the second palette is reset, the first palette takes over and dimming works again.

So for GTK3 we will leave it as is.

For GTK2 I will put in place the conditionals I mentioned in comment #2 to allow those that want vim custom palettes (or similar) can have them provided they set the dimming to 1.0.

Changed in terminator:
status: Triaged → In Progress
Revision history for this message
Stephen Boddy (stephen-j-boddy) wrote :

GTK2 fixed in rev 1682 (not needed for GTK3)

Changed in terminator:
status: In Progress → Fix Committed
Revision history for this message
Egmont Koblinger (egmont-gmail) wrote :

One of those hundreds of vte bugs for which you should push users to the gtk3 version asap :D Maybe you could work around this one, but many others you won't be able to.

Revision history for this message
Brendan (brendan-leason-4) wrote :

In case you weren't aware, for whatever reason the default version of Terminator in the Ubuntu repository is still 0.97, which does not include this fix (amongst many others of course). It's not too difficult to get 0.98 installed, but it would probably make sense to update what is distributed in that repository if you can (I have no idea what the process is).

In addition, is there any practical reason why I should not just use the gtk3 version of Terminator? It seems quite stable.

Revision history for this message
Stephen Boddy (stephen-j-boddy) wrote :

The process for getting a new release into a released version is quite involved as I understand. It's called an SRU (Software Release Update?) and is not something I have any experience of, so I have no idea if it is practical to get it done. We do have stable and nightly PPA's for 0.98.

If the GTK3 version is usable for you, there is no big blocker that I'm aware of. There are a few minor outstanding things, and you may discover new items that nobody has triggered yet. But the more people prepared to use it as their daily driver, the better. One thing with the GTK3 version is that the packaging has not yet been updated, and also the fine manual is not included.

Changed in terminator:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.