Regression in 1.90: saved layouts do not load

[Aleksei Lissitsin]

After upgrade to 1.90 all my saved layouts (screen divided between 4 panes with predefined directories) load in a weird way: it seems that all of the panes are fullscreen, it is possible to close them one by one but there is no way to get them back to 1/4 of the screen.

It does not matter if I load layouts via layout launcher or via -l command line argument.

[Aleksei Lissitsin (aldgracil)]

The upgrade was 1.0 -> 1.90.

[Egmont Koblinger (egmont-gmail)]

Seems to be closely related to (or the same as) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846861.

[Giancarlo Razzolini (grazzolini)]

I can confirm that this bug also happens to me. And yes, it appears to be the same as that bug on the debian bug tracker. Referencing the downstream bug report: https://bugs.archlinux.org/task/52456

[Stephen Boddy (stephen-j-boddy)]

I wonder if this is something to do with our use of the old deprecated VPaned and HPaned widgets. Due to the rebalancing code this could be fairly hairy to update.

@Egmont: you were unable to reproduce. Are you on a similar (or newer) Gtk release as mentioned in the Debian report, i.e. 3.22.2

@Giancarlo: reading the archlinux report, it's not that I'm not accepting any fixes to 1.0 *if someone else provides it*, but rather that *I'm* not going to actively fix things in 1.0. It is better to get the gtk3 regressions fixed up. As I'm learning, stuff breaks in new and interesting ways with so many versions of gtk evolving constantly. So sometimes we get stuff like this. Similar to the transparent background breaking because we had to "fix" it by making quite a few changes.

[Giancarlo Razzolini (grazzolini)]

@Stephen
From the 1.0 release announcement I understood it was not maintained anymore. And, as you say that you yourself is not going to actively fix it, I still think it is not maintained anymore. As I said, I knew things would break with the 1.0 -> 1.90 push. But I think it is better to report bugs and (possibly) patches to actively maintained software, than to play cat and mouse games with rotting software.

Thank you for terminator by the way. I struggled a while after I ditched plasma (and konsole) to find a decent terminal emulator that had support for profiles out of the box and was fast and lightweight.

Archlinux packages gtk3 version 3.22.6.

[Egmont Koblinger (egmont-gmail)]

I'm on Yakkety which means gtk 3.20.9.

[Aleksei Lissitsin (aldgracil)]

Just a small remark. Note that not only old saved layouts (created in terminator 1.0-) load incorrectly but also the newly created (in terminator 1.90) ones.

[Stephen Boddy (stephen-j-boddy)]

Aleksei, if you start terminator from another terminal client (i.e. gnome-terminal) do you see any errors or exceptions on the command line? If so can you paste/attach them here.

Failing that, an output using the -d debug flag might shed some light on this.

As the issue also occurs in Arch which also has 3.22 I'm strongly suspecting that this is the common trigger, and that we need to urgently kill the VPaned/HPaned stuff.

[Stephen Boddy (stephen-j-boddy)]

Can someone seeing this test the following minimal patch? It just removes the explicit use of Gtk.H/VPaned, replacing them with Gtk.Paned. Note this might cause issues elsewhere because I haven't tested everything, but hopefully the layouts will start working again. If not, then the deprecation of the old style Paned widgets has nothing to do with this issue.

Incidentally, I didn't ask if anyone was having problems with normal runtime splits not appearing properly. As the same code is used to split on layout and with a shortcut, I'd expect the manual splitting to misbehave too.

[Aleksei Lissitsin (aldgracil)]

The patch does not seem to do anything: does not break manual tiling, does not fix layout loading.
(I did check that the changes to paned.py actually get compiled and used, e.g., playing with ratio produced bad results.)
So at least you can probably drop deprecated Gtk.(V/H)Paned if you want.

Launching a layout in terminator in either case does not produce any interesting logs (in fact, their were the same logs), see below.

(By the way, playing with ratio in paned.py (e.g., I set ratio=50.5) produced somewhat similar bad results for manual tiling: when splitting to bottom, the old pane gets fullscreen on top, after closing it you can see the new pane. Might there simply be some miscalculations of ratio/size on layout loading?)

UNINTERESTING LOGS (only the first ~7 lines seem to be relevant, the rest is just the result of consequent strokes/mouse movement):

LayoutLauncher::launch_layout: We have takeoff!
LayoutLauncher::launch_layout: Clicked for bredis
str::spawn_new_terminator: Spawning: /home/john/bzr/terminator/./terminator

** (terminator:8529): WARNING **: Binding '<Shift><Control><Alt>a' failed!
Unable to bind hide_window key, another instance/window has it.
Window::on_window_state_changed: Window::on_window_state_changed: fullscreen=False, maximised=False
ConfigBase::get_item: ConfigBase::get_item: title_hide_sizetext found in globals: False
ConfigBase::get_item: ConfigBase::get_item: title_use_system_font found in globals: True
ConfigBase::get_item: ConfigBase::get_item: geometry_hinting found in globals: False
ConfigBase::get_item: ConfigBase::get_item: focus found in globals: click
ConfigBase::get_item: ConfigBase::get_item: focus found in globals: click
ConfigBase::get_item: ConfigBase::get_item: cursor_color_fg found in profile default: True
ConfigBase::get_item: ConfigBase::get_item: title_hide_sizetext found in globals: False
ConfigBase::get_item: ConfigBase::get_item: title_use_system_font found in globals: True
ConfigBase::get_item: ConfigBase::get_item: title_transmit_fg_color found in globals: #ffffff
ConfigBase::get_item: ConfigBase::get_item: title_transmit_bg_color found in globals: #000000
ConfigBase::get_item: ConfigBase::get_item: title_transmit_fg_color found in globals: #ffffff
ConfigBase::get_item: ConfigBase::get_item: title_transmit_bg_color found in globals: #000000
ConfigBase::get_item: ConfigBase::get_item: show_titlebar found in profile default: True
Titlebar::get_desired_visibility: configured visibility: True
ConfigBase::get_item: ConfigBase::get_item: show_titlebar found in profile default: True
ConfigBase::get_item: ConfigBase::get_item: show_titlebar found in profile default: True
Titlebar::get_desired_visibility: configured visibility: True
ConfigBase::get_item: ConfigBase::get_item: show_titlebar found in profile default: True
Titlebar::update_visibility: showing titlebar
ConfigBase::get_item: ConfigBase::get_item: title_hide_sizetext found in globals: False
ConfigBase::get_item: ConfigBase::get_item: title_use_system_font found in globals: True
ConfigBase::get_item: ConfigBase::get_item: title_hide_sizetext found in globals: False
ConfigBase::get_item: ConfigBase::get_item: title_use_system_font fo...

[Aleksei Lissitsin (aldgracil)]

Archlinux now ships gtk3 version 3.22.7. The bug is still present.

[Stephen Boddy (stephen-j-boddy)]

Aleksei, ratio is a float between 0 and 1, where 0 means splitter at extreme left/top and 1 means at the extreme right/bottom. It's probably badly named as you may be thinking of ratio as in 2:1 for example. If you set ratio to 50.5 I would expect to see the behaviour you describe.

When you say that the terminals are stacked can I just confirm that you do not have a splitter at one of the extreme edges of the window contents area? This would mean that the terminals are not stacked. Just that the calculation is wrong, and the "hidden" terminals are actually there, they just have zero size. If so, you would be able to drag the splitters to see all your terminals. (This will obviously be tricky if you use zero sized splitter handles.

Can you attach your config (obviously remove/XXXX any sensitive details) and a screenshot might throw some light on it too.

[Stephen Boddy (stephen-j-boddy)]

I should add that it goes without saying that the problem is still there, still rather confusing, and needs fixing, but if it a ratio/sizing thing, then at least I'd be looking at the right bit of code :-)

[Aleksei Lissitsin (aldgracil)]

My config

[Aleksei Lissitsin (aldgracil)]

Regression behavior

[Aleksei Lissitsin (aldgracil)]

My last testing session was unexpected because now sometimes there is no problem.

At first I thought this could be because of easyscreencapture extension or gnome-shell restart.
But now I even managed to get it working on clean start without the extension.

So this seems like some kind of a race condition (with gnome-shell?).

Before, I was testing on triple (laptop + 2 external) monitors setup. The last testing session was on laptop only.

[Stephen Boddy (stephen-j-boddy)]

OK, So we are indeed narrowing the focus of what the actual issue is, and yup it's looking like a race condition somewhere. My slow old machine generally doesn't give me these problems, so this is why it's a game of 20 questions, and I'm relying on you to help me figure it out.

As I suspected though, the splitter structure is there, so the terminals are not actually stacked. By the look of your webm file the splitter position is a) getting set to zero, or b) getting set before the widget is ready to accept such events.

Out of curiosity does the patch in https://bugs.launchpad.net/bugs/1646257 fix the problem for you? The described symptoms seems very closely related. Two unreproducable (for me) bugs potentially killed with one user-supplied patch? Oh happy days!

[Aleksei Lissitsin (aldgracil)]

No, the patch does not fix the problem.

[Stephen Boddy (stephen-j-boddy)]

Rats! In that case, this will probably be a bitch to fix.

I eyeballed and tested your config, and a see no issue visually or at runtime.

[Stephen Boddy (stephen-j-boddy)]

Hi all, I think I may have tracked this down, and have *a* fix, though I'm not sure it's the *right* fix. I know Egmont in particular doesn't like these kind of "fixes".

So I reproduced it, but for me it's a very rare occurrence, so it's a pain in butt to test. Every so often the get_length function returns 1 when called, instead of giving the correct width or height (depends on split direction). I tried realize()ing and show_all()ing the various widgets, but I still got the mysterious 1 every so often. The attached patch fixed it for me *as far as I can tell*.

Can someone seeing this issue frequently give the attached patch a good few tries to be sure it does/doesn't, and report the results back?

[Aleksei Lissitsin (aldgracil)]

Hi!

This fixes things for me. Yay! Though the fix does seem a little fishy, i.e., the bug looks like it might come back to bite again some day.

Concerning reproducability of the bug, I had it most often when on multiple monitor setup.

[Stephen Boddy (stephen-j-boddy)]

Freakin' awesome!

Like I said, it definitely seems to be a timing issue, and the frequency seems different for different people. The multi-monitor thing could just be the extra load on the system causing the error to happen more easily. I just couldn't figure out how to stop those Paned dimensions coming back with funky sizes.

Anyhow, I'd rather have a fishy fix than a terminal terminator! I'm going to push the fix in and set this to Fix Committed before Egmont tells me I'm doing it wrong ;-)

[Egmont Koblinger (egmont-gmail)]

:D

[Stephen Boddy (stephen-j-boddy)]

Committed revision 1733.