Active tab/panel changes when inactive panel exists

ᛯ terminator -v
terminator 0.95

version from debian

I've committed to trunk a fix for the simple case here - split terminals. They will now only pass focus on to their former siblings if they had focus to begin with. I have not considered the wider cases around windows/tabs to see how this applies there.
I hope this is sufficient for your use case.

Chris, the fix you committed is doing something weird when splitting terms. If I do a simple split I lose all focus and have to use the mouse (or certain key-combos such as Ctrl-Arrow) to activate a terminal before I can type anything.

Probably should have mentioned that it was Rev 1340, lines 114-117 in the changeset that cause the issue. Reverting those 4 lines gives the original behaviour when splitting, but then it doesn't fix the simple case for this issue.

This fixes the issue when splitting. It's a bit kludgy but works. Perhaps it should be getting the metdata with a call, but I was a bit puzzled where to fetch this from. My first few attempts failed, so I went with the kludge ;-)

Stephen: I'm a little confused by the patch - why is it setting had_focus=True for multiple terminals?

Chris: TBH I've forgotten why I did it this way. I think your fix came along that used sibling.grab_focus() call, and is better, but I didn't that solution out. (I did say it was a kludge) Of course now your sibling grabber is ignoring the fact that the terminal exiting may not have focus. Perhaps wrapping those grabs in "if terminal.has_focus():" or similar would fix this bug entirely?

This fix make my terminator totally unusable.

Steps:
* Open terminator
* Split the terminal horizontally 3 times
* type 'exit' on the last created horizontal split
* half-bottom part of terminator screen becomes grey and unusable.

* Red-hat 6.6
* Python 2.6

@ Eduardo: I was looking at this to fix the remaining (for me at least) issue which was Terminator switching to another tab if a terminal closed under that tab. I have fixed this, and quickly tried to check what you were complaining about. Do you still see this? I can't reproduce, and it is not obvious to me what in Chris's sibling.grab_focus patch would cause this.

I'd recommend if you are still seeing an issue (preferably tested in trunk) that you raise a new bug with debug output attached.

Rev. 1634