Skip to content
This repository has been archived by the owner on Jun 4, 2021. It is now read-only.
/ stumpwm-dwm-tiling Public archive

a dynamic tiling solution for stumpwm that follows the lead of dwm

Notifications You must be signed in to change notification settings

szos/stumpwm-dwm-tiling

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

45 Commits
 
 
 
 

Repository files navigation

DWM-Style Groups for StumpWM

NB: This repo is no longer relevant and is out of date. Please see PR #851 in StumpWM for further discussion.

NB: Work is continuing in a fork of StumpWM, in order to ensure good integration. Please see this https://github.com/szos/stumpwm/tree/dynamic-window-management repo for the latest developments

This implements DWM style tiling in StumpWM by defining a new group and associated add and delete window methods. Testers are needed; this group type still causes hangs in certain situations.

Behavior

When creating a new window in a dynamic group with no windows, there is one frame filling the screen with the window in it. When creating the second window, a “stack” is created to the right of the main window, with a horizontal size ratio of 2:1. As windows are added to this group, the most recent window becomes the master window, with all others being placed on the stack. This continues up until (> (length (group-frames group)) *maximum-dynamic-group-windows*), at which point a new group is created as an overflow group. This behavior should change to allow the user to select what happens to the window. Currently there is a restriction - every window must have its own frame.

Currently only one master window is allowed, unlike actual dwm.

When one wishes to switch out the master window for one on the stack, there are two commands one can use: dyn-switch and dyn-switch-to-window. They both take numbers, with the former pulling the window in the frame referenced by the number and the latter pulling the window of that number.

There are also the commands dyn-retile and dyn-balance, which retile all windows and balance the stack tree respectively.

To create dynamic groups one uses gnew-dyn and gnewbg-dyn.

Commands

  • gnew-dyn and gnewbg-dyn - these commands function the same as their regular counterparts.
  • dyn-balance - this is a command used to rebalance the stack. Mostly used for recovering from odd situations where the stack gets unbalanced. should eventually be unneeded.
  • dyn-switch-to-window - This takes a window number and swaps that window with the master window
  • dyn-switch - this draws a frame number indicator and waits for a number to be pressed. The window in that frame gets switched with the master window.
  • dyn-focus - this swaps the current window with the master window.
  • dyn-cycle - this command takes either up or down and cycles in that direction based upon window numbers.
  • dyn-retile - this command triggers an emergency retile. it shouldnt be needed.

Known Issues

Known issues and quirks with how this group type functions.

  • Dialogs - Currently dialog windows cause the current master window to be placed on theb stack. For example, the window opened after adding an addon to firefox will cause the master window to be placed on the stack and the dialog window to take the entire master area.
  • Windows and frames not syncing - Currently, windows and frames should be synced most of the time. However it can occur that they get out of sync. If they do, select the frame and call pull-hidden-next a couple times to get things synced up.
  • Floating windows - Currently, floating windows are fully untested in dynamic groups, and its unknown whether or not they will work or cause massive problems.

Wanted Features

  • Make window insertion into the stack follow stack behavior - When inserting a window into the stack, the window should be placed at the top and all other windows moved down (when needed) to make it appear as an actual stack.
  • Change how cycling works - Cycling through windows should rotate, not swap. Currently as we cycle it just swaps with the appropriate stack window. Instead, it should rotate, with the uppermost or lowermost window being made into the master window, and all other windows being moved up or down while the previous master window gets placed at the bottom or top respectively. Here is an example using 4 windows.
---------------    ---------------
|         | 2 |    |         | 1 |
|    1    | 3 | => |    4    | 2 | =>
|         | 4 |    |         | 3 |
---------------    ---------------

---------------    ---------------
|         | 4 |    |         | 3 |  
|    3    | 1 | => |    1    | 4 | 
|         | 2 |    |         | 1 |
---------------    ---------------

My Testing Procedure

Because StumpWM hangs/freezes in certain situations when using this group, the way I go about testing is as such:

  1. Log in on TTY2 and TTY3
  2. Run startx on both TTY2 and TTY3
  3. In the StumpWM instance running on TTY2, fire up emacs.
  4. In the StumpWM instance running on TTY3, start a swank/slynk server.
  5. Connect to the server running in the StumpWM image on TTY3 from emacs within the StumpWM image running on TTY2.
  6. Navigate to the dwm.lisp file in emacs and press C-c C-l to load the file.
  7. Test things out on TTY3’s StumpWM image.
  8. When StumpWM freezes or crashes, use the REPL in emacs to try and figure out what went wrong.
  9. Reset by running (cl-user::quit), or otherwise restarting the StumpWM image.

About

a dynamic tiling solution for stumpwm that follows the lead of dwm

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages