improvements to tiling windows

This could be a dead-end thought, but one thought i have regarding a hybrid or blended group is to move the concept of tiling type from the group to the frame, and expanding to two major types of frames: window-frames and container-frames. Window-frames can contain either nothing or a window, while container frames contain one or more frames (either window- or container-frames). We could then move the dynamic/auto/tabbed/etc tiling logic from groups to container frames, allowing a blending of the types of tiling used.

Ill give an example using dwm-esq dynamic tiling and manual tiling frames: we create a new group with a single manual-tiling-container-frame (MTCF0) containing a single window-frame (WF0) which itself contains nothing. A window (W0) is added to the group, getting placed into WF0. We then call some command which changes MTCF0 into a dynamic-tiling-container-frame (DTCF0). We add a window (W1) to the group and to DTCF0, causing a new window-frame (WF1) to be created and placing W1 into it. WF0 is moved over to the side, giving us our master/stack split.

At this point our current frame tree is:

(DTCF0
 (WF1 W1)
 (WF0 W0))

And we wish to create a third window which will always be with W1. So we insert around WF1 MTWF1 and add W2 to it, resulting in the frame tree:

(DTWF0
 (MTWF1 
  (WF1 W1 W2))
 (WF0 W0))

At this point we can manually manage W1 and W2, splitting or unsplitting as we wish, while treating them as a single unit in the context of DTWF0. Now we add a fourth window to the group, adding it to DTWF0, moving W1 and W2 onto the window stack as a single unit, resulting in the frame tree:

(DTWF0
 (WF2 W3)
 (MTWF1 
  (WF1 W1 W2))
 (WF0 W0))

And if we wanted to see W1 and W2 side by side we could manually split W1 and W2 into separate frames, resulting in the frame tree:

(DTWF0
 (WF2 W3)
 (MTWF1 
  (WF1 W1)
  (WF3 W2))
 (WF0 W0))

By moving the manual/dynamic/auto/tabbed/etc tiling logic into the domain of frames we could potentially have a manual frame containing a dynamic frame containing an auto frame containing a dynamic frame containing a manual frame (Im not sure what use this level of nesting would be. Perhaps someone has a 60" monitor?). Each container frame would perhaps require a small indicator in the corner telling what type of frame it is, as well as its depth.

Im not sure how the keybindings for moving and cycling between windows/frames would look, but i think there would need to be some different keybindings for navigating in the outermost frame, sub-outermost frame, sub-sub-outermost frame, etc. Perhaps some binding scheme with prefix n for the outermost, prefix C-n for the sub outermost, prefix M-n for the sub sub outermost, and for anything deeper something like prefix C-7 n where 7 is how deep in the tree the navigation should take place.

All in all, i think this system could be useful, but without trying it im unable to say for sure. It could end up being an over engineered and overcomplicated system that fights the user instead of working with them. But as this is a discussion on how tiling would best be implemented i figured it was worth writing this up.

stumpwm / mahogany

improvements to tiling windows #10