(07-12-2020, 02:33 PM)freem Wrote: 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.

Well, "monitoring" is definitely a point I had missed. Indeed, monitoring output from various sources (gdb, log window, etc.) easily eat up an arbitrary number of windows. But on the other hand, more windows per screen means less space per window. So I am really curious what number of windows are acceptable for what size of screens.

I am not familiar with C/S application development, but I feel that all those 9 windows are not "necessary" to some extent. Indeed, all of them are "needed", but that does not imply that they are needed "on screen" at the same time. And that's exactly my intention behind distinguishing "visible" and "available" windows. The 4 monitoring windows are perhaps unavoidable, I guess. But the code editing windows may not be necessary when viewing the logs and gdb outputs, and the terminal is only necessary when you are trying to enter some commands (if I have not misunderstood your intention), under which circumstances you are probably focused on the terminal itself, and letting it float on other windows may be acceptable. A 2x2 grid may still not be adequate, but I believe that if calling out a hidden window or hiding one is as easy as moving the focus, the number of windows necessary *on the screen* can be reduced, and hence gaining more spaces for windows on the screen.

(07-12-2020, 02:33 PM)freem Wrote: 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.

Yes indeed. But as aforementioned, these facilities are just not convenient enough to let you put less on the screen. i3 has only one scratchpad, and once you try to put more than one windows inside, things get rather messy.

(07-12-2020, 02:33 PM)freem Wrote: 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/*

The idea of temp workspace seems attractive to me. I wonder what key you use to switch to/move window to it?

(07-12-2020, 02:33 PM)freem Wrote: 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.

Yes indeed. i3's focus moving strategy is actually based on the internal tree structure, and focus moving in a 2x2 grid layout is just totally unreasonable.



I guess bringing out my idealized window manager here may make my points clearer. If we add a "window list", or "window index" to each workspace, which contains all windows in the workspace, displayed or not, then we can support commands like "swap this window with one in the list" or "call out a window in the index". We may also support putting a complete layout containing multiple windows into the list. This is actually similar to some sort of enhanced scratchpad or pseudo workspace.

My intention behind this design is to make "putting some temporarily unneeded window away, and restore it later" as convenient as possible, so that users can throw away some windows at any time with ease, gaining more screen space, for "necessary" content, without suffering from all the burden to restore the original layout. In my opinion, making every corner on the screen display *something* is not maximizing screen usage, making every corner display something *being watched and used* is the right way to go.