(08-12-2020, 12:31 PM)freem Wrote: Well, it was more like: a system bus and 2 of it's consumers. To reproduce bugs, one often had to trigger inputs from clients in a specific order (yeah, was a joy) thus the 3 debuguers, to "encourage" processes to go in the right path.
The 3 other terminals were for actions inside each process's directory, including checking their logs: they were separate applications. I didn't used a window to edit code, but to read it, because it was more convenient than jumping around with cgdb, especially considering gdb (and cgdb) do not remember the watchers and other stuff natively.

Oh I see your case more clearly now. Thanks for the explanation.

(08-12-2020, 12:31 PM)freem Wrote: Reducing the number of windows on the screens is doable, of course, same as for toggling the fullscreen/floating modes, but that implies bigger context switches for my brain, and things were enough of a mess :D

Please let me do a little survey here:
Q1: Do you think that, with a proper design and efficient hot keys, such "context switching" (changing what windows are displayed) would be acceptable, or if you think that the idea of context switching itself is too much a burden?
Q2: If you feel that context switching may be acceptable in Q1, how many windows are necessary to de *on the screen at the same time* (I don't mean reducing the total number of windows)

(08-12-2020, 12:31 PM)freem Wrote: You could use tab-mode or stack mode, here, combined with marks (same as in vim, but also same as in vim, I don't use them :)), but I guess you'd be annoyed with the title bars? I'm not sure, but I think this can be disabled though.

You're right, i3's tab mode is another thing I like about it. However, it has two annoying issues for me:

1. It does not integrate with tiling layouts well. Once you have a "tab in split" or "split in tab" layout, things get unintuitive and messy.

2. The fact that i3 treat tabbed layouts as part of the tree, like splits, makes creating and managing tabbed layouts a burden.

(08-12-2020, 12:31 PM)freem Wrote: In short, you would like a way to put a container in full screen? That would be awesome, indeed.

If you mean "container" by a layout containing several windows, then probably yes.
More specifically, I mean the follows:
* A window itself is an entity in the list
* A layout that split the screen and assign them to several windows can also be an entity in the list. The layout "points to" the windows rather than "owning" them, so different layouts in the list can share some common windows.
* Every moment, there is a unique layout on the screen. You can swap some of its windows with other windows in the list,
or pull out a complete layout from the list and replace it.

In this way, one can iterate through the possible layouts to use in advance, and switch between them easily later.