(07-10-2020, 05:35 PM)petar Wrote: Hello! I've been using acme for a while now, and I became fascinated with the mouse chords, window management, executing text, and plumbing. Recently I'm becoming more and more frustrated with stacking window managers, but I am not sure which tiling wms support the mouse very well, because I want an experience similar to acme. I know of the various window managers but they always mention powerful keyboard only control. Can you perhaps point me in the right direction to look? Do you have any recommendations? Thanks in advance!

The only tiling wm I know that implements an acme-like interface is wmii.
IIRC, because I don't use it in a long time, you can move windows like in acme with the mouse.
But it is a bit hard to configure.

But for using mouse chords you have to use other programs like sxhkd that bind commands to keyboard/mouse actions.
You may also be interested in writing a plumbing script to use with your wm.

(07-10-2020, 05:44 PM)phillbush Wrote: The only tiling wm I know that implements an acme-like interface is wmii.
IIRC, because I don't use it in a long time, you can move windows like in acme with the mouse.
But it is a bit hard to configure.

But for using mouse chords you have to use other programs like sxhkd that bind commands to keyboard/mouse actions.
You may also be interested in writing a plumbing script to use with your wm.

Right, I'll check these out. Thank you!
I was also wondering about this window manager you wrote; is its source code available somewhere online?

(07-10-2020, 07:06 PM)petar Wrote: I was also wondering about this window manager you wrote; is its source code available somewhere online?

Yes, it is: https://github.com/phillbush/shod
But it is somewhat buggy and I don't recommend you to use it but for testing purposes.

I'm really not satisfied with either stacking or tailing modes of operation. On my 1440p monitor tiling is very wasteful, ironically I feel more claustrophobic with big screen and a tiling wm, yes you use the whole screen all the time, but 70% of it still shows you blank backgrounds of applications. I also hate that text and important things are very spaced out horizontally (if I open two terminals left one will draw text too close to the monitor's edge, while right one will draw text close to center of the screen), I like my windows to be close to center, where my vision naturally goes and not exactly symmetrical in terms of padding/margins from sides/top/bottom of the monitor.
As for stacking I'm not happy how it requires you to manually pick and place windows all the time, yes you can make scripts with wmutils but then it requires big up front effort to come up with these scripts and learn shortcuts for all of them, for example if I want modes for - 2,3 windows side by side, 2 windows vertically, 4 windows in grid manner, 1 browser on the right and vertical grid on the left, and I want them to be dynamic i.e 3 side by side will automatically convert into 2 side by side if i close one window, it will take tons of time to tweak and make it work for my liking. And I'm not even sure if I can pull off very complex logic on my own like tiling-stacking hybrid.
I remain largely unsatisfied with my workflow, it is really not fast or efficient, I just throw things around and drag them if they get in the way.

I'm beginning to realise that full-screen/tiling works for me in many situations but not so much for terminal. The screen is wide, the letters small and that means the eye gets lost moving along the lines. I think that after years, I'll have to experiment with using terminal as a floating window, 80 chars wide.

Been using stacking WM for years now, and I won't go back. Looking into plan9 convinced me that the mouse is not as bad as I though.

Resizing windows with the mouse feels more natural, and quick as you simply point where you want the windows to be, rather than press an arbitrary amount of keys in the hope that it would be enough, and not too much. This meets Dworin's idea of not having too wide terminals.

Another way to "fight" this is by using a terminal multiplexer (though it's just a workaround), or putting the monitor in portrait mode !

I've been on and off with tiling, but mostly off, because it keeps being more in the way and shuffling around windows than I want it to, but every now and then I want to select 2-3 windows and say "tile them like this, ignore everything else".

I've recently discovered an interesting hybrid approach that goes beyond "snap to (maximise|half|quarter)", which is implemented by the app divvy[1]. It can show a small grid on which you can draw a rectangular box that the active window then snaps to, so it makes "manual ad-hoc tiling" quite easy. Probably easier to watch the demo video than try to explain it in writing. It's sadly a bit expensive, and I'm also not sure how actively supported it is. Also no version with X (/Wayland) support.

I think the best and most flexible solution might be some kind of middle ground like that, with stacking by default, but quick and powerful tiling on demand.

[1]: https://mizage.com/divvy/

(25-11-2020, 07:18 AM)sulami Wrote: https://mizage.com/divvy/

>$13.99: Buy now
wow, a wm you have to pay for?

(25-11-2020, 12:40 PM)opFez Wrote: >$13.99: Buy now
wow, a wm you have to pay for?

+$9,999.00 for a Mac ($8,999.00 without a monitor stand)

(25-11-2020, 12:40 PM)opFez Wrote: wow, a wm you have to pay for?

Yeah, it's also on the pricier side. I don't mind paying a few bucks to help fund development on some tools that I use, but this is not really proportional to the value it provides or the market situation.

(25-11-2020, 12:40 PM)opFez Wrote: wow, a wm you have to pay for?

What's wrong with spending a few bucks so the developer can pay the rent?

(25-11-2020, 12:59 PM)stratex Wrote: +$9,999.00 for a Mac ($8,999.00 without a monitor stand)

No.

Just no.

(25-11-2020, 01:41 PM)jkl Wrote: What's wrong with spending a few bucks so the developer can pay the rent?

I'm fine with donations, but paying should be optional.

Would you agree to these conditions if your employer shared these views?

(25-11-2020, 04:14 PM)jkl Wrote: Would you agree to these conditions if your employer shared these views?

If your product is good enough, people who care about it will support it financially.
But we have free markets, so I guess we're stuck with these systems that limit user freedom...

(23-11-2020, 06:34 AM)z3bra Wrote: Resizing windows with the mouse feels more natural, and quick as you simply point where you want the windows to be, rather than press an arbitrary amount of keys in the hope that it would be enough, and not too much. This meets Dworin's idea of not having too wide terminals.

I am now experimenting with a rule to make st centered and small when it's all alone on the display. It will pop back to tiling if anoher window joins. Ironically, resizing st while it's floating messes up the part where it should revert to tiling though. (blame my skills for that).

Hi, new here, but have been reading nixers posts for a while. I have been looking for some in-depth discussions about WMs, and finally I got it here ;)

Many replies have mentioned that a mono application layout turns out to appear most, and that's also my feeling after a ~3 years of pure tiling experience (mainly i3).

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. So I am quite interested about whether people with a large, high resolution screen actually divide their screens in more complex ways...

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. Certainly we have virtual desktops/workspace, but in every WM I have ever seen, they are assigned logical meanings, instead of serving as ad-hoc window containers. 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.

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.

(07-12-2020, 05:31 AM)Guest0x0 Wrote: 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.

That's a point I've never considered: moving between windows based on their visual space on the screen, and not according to some pseudo cyclic order that is often based on the order the windows were last opened.

(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.

Even for those layouts, I've gotten used to 2bwm's default shortcuts to arrange windows in 2x2 or main->2 "slave" relatively easy.

(07-12-2020, 05:31 AM)Guest0x0 Wrote: 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.

I still rely on a single window on each workspace most of the time (<super-[workspace #]>), I'm to used to it. But thinking about this cycling, it's probably the main reason I try to keep each workspace to a maximum of 2 windows (3 at most).

At work I mostly do web development and have to open a browser, probably a PDF/doc depending on the ticket and an incognito window, and end up being forced to cycle through i.e. browser->PDF->incog, when I only need browser->incog.

I could easily move the PDF to a different workspace, but then I'd have to use less accessible keybinds like <super-6> since the most accessible ones are already occupied by other stuff I use.

(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.

(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.

(08-12-2020, 04:29 AM)Guest0x0 Wrote: My intention behind this design is to make "putting some temporarily unneeded window away, and restore it later" as convenient as possible

I also like the idea of temporary windows. Maybe a visual clue would be helpful, like making them translucent when they are shown.

Another idea would be to play with work-area space. Mcol is currently working on an infinite workspace window manager where you can zoom and pan in or out to get to the windows or area you want.
You could insert the concept of temporary windows in it by adding a Z layer to this, windows living on another layer could be brought back to the workspace whenever needed. Like tools in a toolbox on your side that you can put on your desk when needed.

Having infinite canvas is interesting idea, our brain actually maps spatial information much better than numeral. Very long time ago I was playing with "galapix" GPU accelerated image viewer, it was surreal to see how fast you can zoom in and out of tens of thousands of images. But I see some issues applying this concept to window managers, first is navigation, if you make zoom levels discrete (so that you can press keys to zoom) it won't feel smooth and natural, if you make some kind of ease-in, ease-out it will feel sluggish and slow, and if you make zoom truly analog you would have to use your mouse to zoom-in-out, not great for keyboard driven WM. Second is GPU acceleration, I may be wrong on this one, but how would you draw huge canvas without GPU involvement, of course you would have to code for GPU, something tells me it will be infinite amount of pain shoved to your ass to code this and maintain afterwards.

(08-12-2020, 04:29 AM)Guest0x0 Wrote: 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.

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.
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

(08-12-2020, 04:29 AM)Guest0x0 Wrote: The idea of temp workspace seems attractive to me. I wonder what key you use to switch to/move window to it?

Same as for normal workspaces, the point here was purely semantic. Also, 5 and 6, because it lets me have 4 workspaces on my main screen which is on the left side, 2 "floating" ones, 3 on the secondary screen which is on right side, and a mail+monitoring and other minor stuff (with xosview: https://xosview.sourceforge.net) on the secondary screen, fixed on the wp 0.
It works with having most workspaces tied to a specific screen. I also have a shortcut which allows me to move to and from main screen without having to remember which workspace is currently enabled there.

In short: moving something to temp wp5: $mod+shift+5. Bringing it back implies going there, focus it, and $mod+shift+5 again (I like back-and-forth feature).
If I needed that way of doing things, I'd probably tinker a script based on xdotools and i3-msg though. I recently used xdotool to build a script that "spawns/update an unfocused window" when I update a specific file: http://www.deadbeef.fr/projects/dotter/f...tcher.html . It's not clean, but it works, even if yes, I think it should be a lot easier... hum, actually, this gave me an idea... I may improve that soon :)

(08-12-2020, 04:29 AM)Guest0x0 Wrote: 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.

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.

(08-12-2020, 04:29 AM)Guest0x0 Wrote: 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.

In short, you would like a way to put a container in full screen? That would be awesome, indeed.

(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.

(09-12-2020, 12:13 AM)Guest0x0 Wrote: 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?

I think what do the context switch is the image changing too much. I can't really explain that though, and I've been proved to be wrong on multiple occasions when things come to UI (I don't enjoy building those things anyway).

(09-12-2020, 12:13 AM)Guest0x0 Wrote: 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)

I honestly don't know. I think it depends a lot on the number of glyphs you can show per window. Yes, of glyphs, not of pixels, nor of icons nor... glyphs. Because when I work, I work with text.
I think a comfortable setup requires at least a 2x2 grid of at least 80 columns for 30 lines. That's because I use C++ mostly, where I try hard to keep short blocks. With shell scripting or reading logs, for example, I don't split my screens vertically, but I can work with less than 10 lines shown.
That's per screen, for a normal usage (means: not debuging multiple processes at a time, nightmare is probably worse when using faster IPCs or threads).
I use roughly the same setup for my mails and web browser as for my C++ code, too. Not because of the 80x25 tradition of TTYs, mind you, but because I hate having to move my eyes and neck to read a complete line of code.

(09-12-2020, 12:13 AM)Guest0x0 Wrote: 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.

Yes, but I think it's because i3's control are not nice. It is bloated (imo) with features people rarely use, yet moving the focus correctly is hard. Well, I suppose one could just put a mark on windows to jump there, but my brain does not work like a CPU, I don't have an IP register nor a call stack in there.

(09-12-2020, 12:13 AM)Guest0x0 Wrote: f you mean "container" by a layout containing several windows, then probably yes.

Container is the original words from i3's doc, IIRC. Its also used, for example, in wxWidgets AUI API (https://docs.wxwidgets.org/3.0/group__gr...__aui.html)

(09-12-2020, 02:35 PM)freem Wrote: I think a comfortable setup requires at least a 2x2 grid of at least 80 columns for 30 lines. That's because I use C++ mostly, where I try hard to keep short blocks. With shell scripting or reading logs, for example, I don't split my screens vertically, but I can work with less than 10 lines shown.

That's the exact issue that drove me to rethink about the "maximize screen usage" benefit of tiling WMs. Even if one has all windows needed on screen, it is meaningless if each window has too little space. If the physical screen space is inadequate, making full use of it doesn't really solve the issue. Now that we can't put everything on screen comfortably anyway, can we cut some unnecessary content from screen then? Can we only display those windows that are *absolutely necessary* at each moment? As you have noticed, to achieve this goal, a lot of context switching is necessary, since what is "absolutely necessary" changes frequently. Hence my two questions: is it possible to make such frequent context switching affordable? And how much screen space we can squeeze if so?

(09-12-2020, 02:35 PM)freem Wrote: Well, I suppose one could just put a mark on windows to jump there, but my brain does not work like a CPU, I don't have an IP register nor a call stack in there.

You might be interested in i3-easyfocus, which provides a way to jump to windows like those VIM browser plugins: some one or two letter labels are drawn on each window, and typing the label will jump to the corresponding window.

(09-12-2020, 02:35 PM)freem Wrote: Container is the original words from i3's doc, IIRC. Its also used, for example, in wxWidgets AUI API (https://docs.wxwidgets.org/3.0/group__gr...__aui.html)

Well, I have used the word "layout" for similar things in previous replies, then. Jumping back to the origin of this quotation list, my idea is to "poolize" windows and/or layouts (containers) per workspace. Every moment exactly one layout (may contain only window as well) will be displayed on the screen, but there may be many others in the "pool". And one can call out things in the pool conveniently.

Take the use case of debugging a C/S application with one client and one server (for simplicity) for example (hopefully I am not misunderstanding the actual case). In the "pool", there are two gdb windows, two log windows, two terminals and perhaps two code windows. You may as well put layouts you may need in the "pool", for example, you can put the following stuffs in the pool:

* a "monitoring" layout, which contains the two gdb windows and the two log windows
* the "manipulate server" layout, which contains the server terminal, code window, he server gdb and log window.
* similarly a "manipulate client" layout.

Now assume you are in the monitoring layout and find something interesting from the server side, and you decide to call some commands on the server side to further investigate your findings, you can simply call out the "manipulate server" layout and perform you operations, and switch back to the "monitoring" layout afterwards.