(07-12-2020, 05:31 AM)Guest0x0 Wrote: Now I am rather convinced that 99% use cases can be covered by a layout no more complex than a 2x2 grid, and complex layouts beyond this are just unnecessary. However this is a biased opinion, as I use only a 14-inch laptop monitor most of times, with an extra 27'' one only occasionally.

2 things here.
1: try to build, and debug, a client-server application. When you need to debug 2 different client implementations and the server at same time. Good luck with a 2x2 grid if only using gdb (1 gdb instance per process + 1 log window per process + at least one terminal per process, already 9 windows here). Sure, that's not 99% of usages, but now, tiling window managers are not for 99% of usages: who needs a tiling WM when they want to go on facebook or send that MS office document to the boss? Stacking is enough for that. And *that's* 99% of usages.

If you know a good gdb frontend which is not a full blown IDE, please share, I'm sure that could help me a lot here.
Note that the gdb (ok, if you know a frontend for lldb, I'd be happy too) commandline must be easily accessed with keyboard.
Personally, I use cgdb. This one's okay, but I'm still loosing a lot of time when I need to start it (end result is, I spend more time making code debuggable without a debugger, which is a pretty good thing anyway).

2: you use it most of the time in a way I probably never did: single screen of average size.

I personally almost always either had a small screen (10.1") or at least 2 screens, up to 3 (from small ones to medium ones, when at home, screens are of different sizes, but not at work, which makes things a lot easier).
In each situation, I worked differently:

* with the smaller screen, I almost never had more than 1 window per workspace, except some temporary manpage;
* with more than one screen, up to 3 (never had more, and even the 3 screens setup was quite hacky at that time, i3 didn't shined on having more than 1 GPU, and yes, it was an i3's problem, xorg had no issue with that), one of the big wins is the ability to instantly move from a screen to another.

One of my favorite layout on small screens is: 1 main window taking all height and showing at least 65 columns, ideally 85, then a vertical container containing build log, man pages, access to headers, etc. When I focus out of code, either I already have information on screen (no focus change) or I temporarily enlarge the vertical container to have wider lines. In extreme cases, I just make the window I want fullscreen.
Sometimes I also split the main window's height to have a 2nd code window. All of this, and I still have my 2nd screen.

(07-12-2020, 05:31 AM)Guest0x0 Wrote: Another downside of tiling WMs, according to my own observation, is the ignorance of "stacking" or "hiding" of windows. Tiling WMs tend to encourage people to put everything on the screen, which is probably not the best practice.

I disagree here. Every tiling WMs I've looked at claimed to support for modes which are neither pure tiling nor floating: stacks and tabs. I personally use them a lot, because my screens are pretty shitty, one have damaged areas and the other one have a resolution of 1366x768, so can't put much in it: I even now try to keep my lines of code below the 60 columns, to be able to show 2 files side by side :/
Honestly, I also do that (use the stacks and tabs) when I have better screens.
BTW... i3 have a "scratchpad" workspace too, which I don't use, but it seems to be something you might enjoy.

(07-12-2020, 05:31 AM)Guest0x0 Wrote: For example, when I am developing a C++ program, but has something unsure about the standard, and decided to do some experiments in another test project, it would be weird to put the new project on my "web browsing" or "doc reading" workspace, instead of the "code editing" one, just because my screen can't fit two projects at the same time.

well, I do that quite often. WHat is really weird is to force yourself to do something inefficient because "it would be weird". Things I use the most in my i3 layout are:

* $mod + t (because t is at center of keyboard) to spawn a terminal
* $mod + shift + t to spawn a terminal *in /tmp/*

At a time, I even had some set of scripts and bindings to affect a path to my workspaces. In the end, I don't think it's that useful, because I use a shell which have a powerful completion system and that does not wastes me much time to just `cd ~/d/p/foo/s<tab>` to reach `$HOME/devel/projects/foo/src/` directory.
Fact is, with a tiling window manager, it's easy to spawn and throw away a set of windows which will naturally *not* waste screen space, and as a bonus point, usually no need to reach the mouse.

(07-12-2020, 05:31 AM)Guest0x0 Wrote: Finally I realized that the essence is that, the windows we want to be "available" are different from the windows we want to be "displayed on screen". Instead of struggling to put everything you need on the screen, convenient methods to hide/show windows and/or simple layout of windows is the right way to go for me.

But one thing I really love about (some) tiling WMs is the way you move the focus. Most stacking WMs and some tiling WMs move focus by some sort of Tab-cycle, but the order is not visible from the visual layout of windows, so you have to switch focus, see which window is focused and then interact, which is slow, considered that moving focus is the most frequent operation when using a WM. But some tiling WMs support moving focus by directions. In this way, where you'll move to is directly visible from what you see , no thinking or interacting is required.

Considering the fact I use stacks, tabs and workspaces a lot, I'd say it's not that true. When I have too many workspaces around (and for a time, I had to do that client-server debugging + keep an eye on servers + other tasks... 10 workspaces were no longer enough), I tend to cycle over them. Probably because I didn't tweaked my environment enough, sure, and also because I like keeping "floating workspaces" which can go on any of my screens: usually 5 and 6, which makes 4 "static" ones and 1 "floating" per screen. With a 3rd screen, I'd need 15 workspaces to stay organized.

FWIW, I switched to i3 years ago, I don't know how many exactly, but probably around 10. Not saying I master it or have seen everything and you're wrong, far from it. It's just to point the fact that my usage constantly changed in that time span, for various reasons: different hardware, different tasks, different mood, my vision of things changing...

There are, though, things I do not like at all with i3: it have *a shitty focus move system* which is NOT related to space organization but to memory (as in: RAM) organization.
There are other problems, but this one is the most annoying imo.

PS: welcome.