Comment 8 for bug 1646257

If you open a second tab and then split then it's also broken.

That is: Splitting a tab is broken, splitting a pane is sometimes broken, splitting the entire window works correctly.

Splitting the entire window (that is, the first Ctrl+Shift+E or O keypress) flashes up "None None" in a gray bar at the top of the window for a short moment. That is, the titlebar (that's supposed to be disabled) is visible for a short while.

This back-n-forth toggling could be the one that accidentally triggers fixing the layout. Or not, since in the default "titlebar enabled" case it's not a back-n-forth, and it still works. Dunno.

My generic _feelings_ (without seeing what the actual bug is):

Probably a big cleanup along the lines of bug 1522542 is required.

Terminator is stuffed all over the place with "while Gtk.events_pending(): Gtk.main_iteration_do(False)". I believe this is a bad programming practice. In gtk2 it might have been a great workaround for plenty of things, in gtk3 this rather causes an uncontrollable mess.

The entire new layout should be imagined and then defined in one step, without giving the control back to gtk's main loop halfway that updates the UI for that partial solution and then noone knows how the rest of the story continues.

"while Gtk.events_pending(): Gtk.main_iteration_do(False)" is only okay after the entire new layout has been defined, and after this step we only do things that no longer influence the layout, e.g. focus a certain widget.

I have a strong feeling that a generic cleanup along these lines will lead to this bug magically vanishing.

Also there's too much code duplication (triplication -- is there such a word? :)) since window.py, notebook.py and paned.py pretty much define the same steps to be executed for these three kinds of Gtk objects. It would be great to clean them up, and e.g. have one single split_axis() that knows how to replace any of these widgets with a Paned. But that's probably too much for now.