SHOD(1)

πŸ“¦ version 2.6.2, in nixos 26.05, nixpkgs unstable

Bestie, welcome to the General Commands Manual page for shod and shodc, aka SHOD(1) β€” we're doing this, and it's gonna be a whole vibe. πŸ’…

🌸 NAME 🌸

shod, shodc β€” mouse-focused window manager

✨ SYNOPSIS ✨

shod [-AcdhstW] [file]

shodc close [win_id]
shodc cycle [-s]
shodc desk
shodc exit
shodc focus [-clrtbpnLRTBPN] [win_id]
shodc geom [-r] [-x N] [-y N] [-w N] [-h N] [win_id]
shodc goto [-m mon_id] desk_id
shodc list [-ls] [win_id]
shodc sendto [-m mon_id] desk_id [win_id]
shodc state [-ATR] [-abfMmsy] [win_id]

πŸ’– DESCRIPTION πŸ’–

Okay so shod is a multi-monitor floating reparenting X11 window manager which supports tiled and tabbed containers. It's giving main character energy, honestly.

shod works only via mouse with a given key modifier (Alt by default) and by responding to client messages β€” and yep, it is needed a controller called shodc to control shod. Iykyk. 🫢

If a file is given as argument, shod passes this file to sh(1) to run the commands in that file after shod has initialized itself. However, if the argument is an hyphen (-), shod calls sh(1) to run commands read from the standard input instead. Literally that simple. ✨

The options are as follows, bestie:

  • -A β€” Use "Alt" as modifier key. More technically, use "Alt_L" as the key to perform container cycling (alt-tab); and use "Mod1Mask" as the modifier for mouse operations. This option is incompatible with -W.
  • -c β€” Honor configure requests. By default, shod ignore requests to configure a window size or position after the window is mapped. A client may request the window manager to configure (i.e., resize or reposition) its own window. For example, xterm(1) sends a configure request for the window manager to resize its window when the user changes its font size. Clients requesting to change its own size may be annoying, so configure requests are ignored by default; but they can be honored by invoking shod with the -c command-line option.
  • -d β€” Make dialogs float. By default, dialog windows are mapped inside the client window. With this option, dialogs are floating windows instead. (Technically, this option makes dialog windows behave the same as menu windows.)
  • -h β€” Disable setting obscured windows as hidden. By default, windows whose containers are obscured by other containers are set as hidden (aka minimized). This default behavior emulates the way Plan9's rio lists obscured windows as hidden. With this option set, only manually minimized containers are set as hidden.
  • -s β€” Use sloppy focus rather than click-to-focus. πŸ¦‹
  • -t β€” Disable container cycling (aka β€œalt-tab”).
  • -W β€” Use "Super" (also known as "Window Key") as modifier key. More technically, use "Super_L" as the key to perform container cycling (alt-tab); and use "Mod4Mask" as the modifier for mouse operations. This option is incompatible with -A.

shodc is the remote controller for shod. Its first argument must be an operation to be performed. The following arguments are the options for the operation (each operation accepts a different set of options). The last arguments are the operation's arguments, such as a window ID or a desktop ID. No cap. πŸ‘‘

Known operations for shodc are listed below.

πŸŽ€ Close window πŸŽ€

The close operation closes a window whose ID is provided as argument. If no argument is provided, close the active window. Bye bestie. πŸ’€

πŸŽ€ Cycle containers πŸŽ€

The cycle operation initiates the cycling through the open containers on the current desktop. This cycling is generally called "alt-tab". Cycling is performed as "Tab" is pressed, and terminates when the modifier key is released. (The synopsis shows shodc cycle [-s], and this section explains the cycling behavior itself.)

πŸŽ€ List desktops πŸŽ€

The desk operation β€” aka desks in the prose, iconic β€” lists the desktops, one per line.

If the line begins with an asterisk, the desktop is the focused one; If the line begins with an hyphen, the desktop has an urgent window in it. The number is the number of windows in the desktop. ⭐

πŸŽ€ Exit shod πŸŽ€

The exit operation exits the shod window manager. Closing time, fr fr. 🫢

πŸŽ€ Focus window πŸŽ€

The focus operation focuses a window whose ID is provided as argument. If an option is provided, focus a window relative to the window provided as argument.

The options are as follows:

  • -c β€” Cycle focus. This option only makes sense when using -n, -p, -N, or -P.
  • -l β€” Focus window in the closest container to the left of the container of the window provided as argument (or the active window, if no argument is provided).
  • -r β€” Focus window in the closest container to the right of the container of the window provided as argument (or the active window, if no argument is provided).
  • -t β€” Focus window in the closest container on the top of the container of the window provided as argument (or the active window, if no argument is provided).
  • -b β€” Focus window in the closest container on the bottom of the container of the window provided as argument (or the active window, if no argument is provided).
  • -p β€” Focus window in the previous container in the focus list in relation to the container of the window provided as argument (or the active window, if no argument is provided).
  • -n β€” Focus window in the next container in the focus list in relation to the container of the window provided as argument (or the active window, if no argument is provided).
  • -L β€” Focus window in the column to the left of the window provided as argument (or the active window, if no argument is provided).
  • -R β€” Focus window in the column to the right of the window provided as argument (or the active window, if no argument is provided).
  • -T β€” Focus window in the row above (on the top of) the window provided as argument (or the active window, if no argument is provided).
  • -B β€” Focus window in the row below (on the bottom of) the window provided as argument (or the active window, if no argument is provided).
  • -P β€” Focus window in the tab previous to the window provided as argument (or the active window, if no argument is provided).
  • -N β€” Focus window in the tab next to the window provided as argument (or the active window, if no argument is provided).

πŸŽ€ Set geometry πŸŽ€

The geom operation sets the geometry (position and size) of the container of the window whose ID is provided as argument. If no argument is provided, sets the geometry of the container of the active window. If no position (set by the options -x and -y) is provided, move window to position 0,0 (top left corner). Slay that placement. πŸ“

The options are as follows:

  • -r β€” Relative. All position and size values are relative to the container's current position and size.
  • -x N β€” Set the position on the X axis to N.
  • -y N β€” Set the position on the Y axis to N.
  • -w N β€” Set the width of the container to N.
  • -h N β€” Set the height of the container to N.

πŸŽ€ Go to desktop πŸŽ€

The goto operation goes to the desktop ID provided as argument. Different from other window managers, shod counts desktop from 1; So the first desktop is the desktop 1, not the desktop 0. Numbering icon behavior. πŸ‘‘

The options are as follows:

  • -M monitor β€” Goes to a desktop on the provided monitor rather than on the currently focused monitor. Monitors are counted from 1, not from 0.
Heads up, bestie: the synopsis line spells this as -m mon_id, while the option text says -M monitor β€” I'm keeping both exactly as the page gives them.

πŸŽ€ List windows πŸŽ€

The list operation lists windows, one entry per line. If a window ID is provided as argument, list only this window.

The options are as follows:

  • -l β€” Long list format. More information on this format below.
  • -s β€” Sort by stacking order.

If the -l option is given, the following information (delimited by tabs) is displayed for each window, in the following order:

  1. Window state.
  2. Window desktop.
  3. Window geometry (size and position).
  4. ID of the container the window is on.
  5. ID of the row the window is on.
  6. ID of the window.
  7. Name of the window.

The window state consists of a sequence of eight characters, each one meaning a state for the container. If a character is an hyphen (-) the state is not set or does not apply to the window. The state characters, in the order they appear, are the following:

  1. An β€œy” indicates that the window's container is sticky.
  2. An β€œM” indicates that the window's container is maximized.
  3. An β€œm” indicates that the window's container is minimized.
  4. An β€œf” indicates that the window's container is fullscreen.
  5. An β€œs” indicates that the window's container is shaded.
  6. An β€œa” indicates that the window's container is above others. An β€œb” indicates that the window's container is below others.
  7. An β€œu” indicates that the window has the urgency hint set. An β€œa” indicates that the window demands attention. An β€œU” indicates that the window is both urgent and demands attention.
  8. An β€œa” indicates that the window is active. An β€œf” indicates that the window is focused. An β€œF” indicates that the window is both active and focused.

πŸŽ€ Send to desktop πŸŽ€

The sendto operation sends to the desktop ID provided as first argument the container of the window whose ID is provided as second argument. If no window ID is provided, sends the container of the active window to that desktop. Different from other window managers, shod counts desktop from 1; so the first desktop is the desktop 1, not the desktop 0.

The options are as follows:

  • -M monitor β€” Sends to a desktop on the provided monitor rather than on the currently focused monitor. Monitors are counted from 1, not from 0.
Same cute little spelling situation here: synopsis says -m mon_id, option text says -M monitor, and both stay exactly as given. 🫢

πŸŽ€ Set container state πŸŽ€

The state operation sets the state of the container of the window whose ID is provided as argument. If no argument is provided, sets the state of the container of the active window.

The options are as follows:

  • -a β€” Above. Raise container above others.
  • -b β€” Below. Lower container below others.
  • -f β€” Fullscreen. Make container fullscreen.
  • -M β€” Maximized. Maximize container.
  • -m β€” Minimized. Minimize container.
  • -s β€” Shaded. The container is resized to fit its titlebars.
  • -y β€” Sticky. Stick container to the monitor.
  • -A β€” Add state. Force state to be set.
  • -T β€” Toggle state. Set state if it is unset, or unset it if it is set. This is the default.
  • -R β€” Remove state. Force state to be unset.

✨ USAGE ✨

Okay bestie, so shod keeps one virtual monitor for each physical monitor found by Xinerama(3). One of those monitors is the focused one β€” that’s where new windows go when they’re created. Each monitor has its own different set of virtual desktops (or just β€œdesktop” for short), and one desktop per monitor is the focused desktop for that monitor. Slay.

Each monitor has an area called the β€œcontainer area”, and within it containers are spawned and can be maximized. The size and position of a monitor’s container area can be changed by bars and the dock. Iconic.

Most client windows are displayed in containers, but some windows are special and get displayed in different ways. Buckle up.

🧚 Containers 🧚

Containers are floating windows. A container contains sub-windows (called tiles) organized in columns, rows, and tabs; each tile represents a client and can have dialog windows and menu windows associated with it. A new container is created in the focused desktop of the focused monitor, and this new container is placed in an empty area of the screen. Periodt.

A container has borders (four edge handles and four corner handles) around it; borders are always visible, except when the container is fullscreen. Borders are used to move and resize containers β€” more info on that below. A container has divisors between its columns, and between the rows within each column. Divisors are used to resize the tiles by dragging them with the first mouse button. A container has title bars above each row. Title bars contain tabs, the left (stack) button, and the right (close) button. More info on those below too.

Keyboard input goes to the focused client of the focused container. A container can be focused by clicking on it with the 1st mouse button; the click is passed to the application, which can process it in a particular way. The focused container is decorated with a visually distinct decoration (blue in the default theme); while other containers have either the common decoration (gray in the default theme), or have the urgent decoration (red in the default theme). The vibes are color-coded, iykyk.

Containers are stacked one above the other in the virtual Z axis. The position of the container in this Z axis can be changed by an operation called β€œraising”. A container can be raised by clicking on it with the 1st mouse button. The list of containers in this Z axis, from the one at the bottom to the topmost, is called the β€œstacking order”. The stacking order is organized in four layers. When a container is raised, it moves to the top of its layers. The layers are the following (from bottomost to topmost):

  1. The bottom layer (for containers below others).
  2. The middle layer (for normal containers).
  3. The upper layer (for containers above others).
  4. The fullscreen layer (for fullscreen containers).

Each container can have one or more of the following states:

  • Maximized β€” the container occupies the entire container area.
  • Fullscreen β€” the container occupies the entire monitor and its borders are hidden.
  • Minimized β€” the container is not shown on the monitor.
  • Shaded β€” the container is resized to show only the title bars.
  • Sticky β€” the container is stickied to the monitor, and appears on the screen no matter which desktop is selected.
  • Above/Below β€” those two states are mutually exclusive. The container is raised above or lowered below other containers.

A non-fullscreen, non-maximized container can be moved by the following methods:

  • By dragging the container border with the third mouse button.
  • By dragging a title bar with the first mouse button. Or
  • By pressing the modifier key and dragging any part of the container with the first mouse button.

Each title-bar has tabs, which displayes the title of its client. Dragging a tab with the first mouse button moves the entire container. Dragging a tab with the third mouse button detaches the tab from the container. A detached tab, while being dragged, can be reattached into another container (or the same container) by dropping it on the title bar, border or divisor; or can be made into a new container by dropping it elsewhere. Double-clicking a tab toggles maximization of its container. Obsessed with the drag-and-drop lore.

Each title bar has a left button. Clicking on the left title-bar button with the first mouse button restackes the column by maximizing its rows (and minimizing the other rows in the same column), or undoes this state.

Each title bar has a right button. Clicking on the right title-bar button with the first mouse button closes the focused client or its top dialog.

Containers can be cycled using the modifier key set with either the -A or -W command-line option (Alt_L by default) followed by the Tab key. The Tab key can be further modified by Shift to cycle in the oposite direction. This mechanism is usually called β€œalt-tab” because of the key combination that usually triggers it. This mechanism can be turned off by invoking shod with the -t command-line option. No cap.

πŸ¦‹ Dialog πŸ¦‹

Windows that are transient for another managed windows (called its leader) are mapped in the center of the leader.

Dialogs are small windows that communicates information to the user or prompts for a response.

shod only changes the position and size of a dialog window when the size of its leader changes. Respectful king behavior, honestly.

🌸 Splash screens 🌸

Windows of type _NET_WM_WINDOW_TYPE_SPLASH (called splash screens) are mapped above all other windows and are stacked on the order they are spawned. Splash screens cannot be manipulated. Splash screens have no decoration around them.

Splash screens are transient windows that appear temporarily while an application is loading.

shod centers the splash screen on the monitor. Cute.

windows of type _NET_WM_WINDOW_TYPE_MENU, _NET_WM_WINDOW_TYPE_UTILITY, _NET_WM_WINDOW_TYPE_TOOLBAR, or MWM_TEAROFF_WINDOW (called menu windows) are windows that cannot be tiled or tabbed into a container and are optionally tied to a leader window. They are floating windows that always apear on top of their leader and are not listed on the list of clients. If a menu has no leader window, they apear on top of all windows.

Menu windows, often called β€œtorn off windows”, are pinnable menus, utility windows, and toolbar windows (ie', toolbar and menus "torn off" from the main application).

The user can change the position of a menu window in the same way of changing the position of a container. Same energy, different window type.

🫢 Prompt 🫢

A window of type _NET_WM_WINDOW_TYPE_PROMPT (called prompt window) is mapped on the top of the focused monitor. This window will stay focused and mapped until be closed, or a mouse button is pressed outside that window. This is an EWMH extention, only used by xprompt(1). Very niche, very iconic.

shod does not change the size of the prompt window. However, shod changes its position.

πŸ’œ Desktop windows πŸ’œ

Windows of type _NET_WM_WINDOW_TYPE_DESKTOP (called desktop windows) are mapped below all other windows and are stacked on the order they are spawned. Desktop windows cannot be manipulated. Desktop windows have no decoration around them.

Desktop windows indicates a desktop feature. That includes windows such as conky(1) and windows that manage desktop icons.

shod does not change the size nor the position of desktop windows. Hands off, bestie.

πŸ”₯ Notifications πŸ”₯

Windows of type _NET_WM_WINDOW_TYPE_NOTIFICATION (called notifications) are popped up on the top right corner, one above another. Notification windows cannot be manipulated. Notification windows have a decoration around them; this decoration is the same as the borders of the active container (or, for urgent notifications, the same as the borders of an urgent container).

An example of a notification window would be a bubble appearing with informative text such as β€œYour laptop is running out of power” etc. We’ve all seen her.

shod can change the size and the position of notification windows.

🌈 Bars 🌈

Windows of type _NET_WM_WINDOW_TYPE_DOCK (called panels, bars, or external docks (to distinguish them from shod .Ns 's internal dock)) are mapped on a side of a monitor. Dock windows cannot be manipulated, have no decoration and do not receive input focus.

A bar window can change the size of a region of the monitor called β€œcontainer area”. The container area is the region of the monitor that a maximized container occupies. The container area is also the region of the monitor inside which containers are spawned.

Examples of bar are a taskbar that shows which programs are currently running, or a status bar that shows information about the system.

shod does not change the size nor the position of bar windows. Not her job, not her problem.

πŸ“ Dockapps πŸ“

Windows that initiate in the WithdrawnState (called dockapps) are mapped inside the dock. The dock is a panel or bar that appears on the edge of the first monitor. Inside the dock, dockapps are organized by order of map request.

Dockapps, or docked applications are windows which appear to reside inside an icon or a dock rather than a container. Tiny little residents, honestly.

Dockapps can have one of three possible states: spaced, shrunk, or extended. The state of a dockapp can be set with the shod.CLASS.NAME.ROLE.state X resource.

A β€œspaced” dockapp is centered on a slot whose size is multiple of, by default, 64 pixels (this value can be changed with the shod.dockSpace X resource). So for example, by default, if a dockapp has 58 pixels, it is centered on a slot of 64 pixels (64 * 1); but if a dockapp has 100 pixels, it is centered on a slot of 128 pixels (64 * 2). This is the default state for a dockapp.

A β€œshrunk” dockapp has its slot resized to the size of the dockapp itself.

An β€œextended” dockapp is resized to fit all the remaining unused space of the dock. For example, if the only content of the dock is an extended taskbar dockapp, this dockapp is resized to fit all the dock.

an β€œresized” dockapp is resized to fit the width of the dock (that is, the width of a vertical dock or the height of an horizontal dock). πŸ’…

🌸 RESOURCES 🌸

okay bestie, shod also understands these X resources, and yes, you need the whole list β€” no skipping the β€œboring” ones, that’s not the vibe πŸ’…

  • shod.borderWidth β€” the width of the borders and divisions. simple, iconic, does exactly what it says πŸŽ€
  • shod.activeBackground, shod.activeTopShadowColor, and shod.activeBottomShadowColor β€” the body color, light shadow color, and dark shadow color for the 3D effect of the borders and title bars of active windows. it’s giving active-window glow-up ✨
  • shod.dockBackground, and shod.dockBorder β€” the background color and border color for the dock. dock drip check πŸ’…
  • shod.dockGravity β€” where the dock sits, described with up to two uppercase letters. the first letter (E, N, W or S) says which edge of the monitor β€” East, North, West or South β€” to align the dock to. the optional second letter (E, N, W, S, C or F) says which corner of that edge of the monitor to align the dock to; a C means the dock should be centered on that edge, and an F means the dock should be stretched to fill that edge. if no second letter is supplied, the dock is centered on that edge. for example, with NE, a horizontal dock will be placed in the north edge of the monitor, aligned to the northeast corner. and with EF, a vertical dock will be placed in the east edge of the monitor, stretched to the full height of the monitor. placement queen πŸ‘‘
  • shod.dockSpace β€” the multiplier for the height (for vertical docks) or width (for horizontal docks) in pixels of the slot dockapps are placed in. see the section β€œDockapps” above for more information 🧚
  • shod.dockWidth β€” the width (for vertical docks) or height (for horizontal docks) of the dock in pixels. defaults to 64 (the size of most dockapps). tiny dock, big personality πŸ“
  • shod.inactiveBackground, shod.inactiveTopShadowColor, and shod.inactiveBottomShadowColor β€” the body color, light shadow color, and dark shadow color for the 3D effect of the borders and title bars of inactive windows. the β€œnot your main character right now” palette πŸŒ™
  • shod.numOfDesktops β€” the number of desktops for each monitor. the default is 10 desktops for each monitor. ten little worlds, fr fr 🌈
  • shod.notifGap β€” the gap in pixels between notifications. personal space for your pop-ups 🫢
  • shod.notifGravity β€” the placement of the dock in uppercase abbreviated points of the compass. for example, a value of NE will place notifications on the northeast edge of the screen. compass-coordinated notifications, iykyk 🧭
  • shod.shadowThickness β€” thickness of the 3D shadow effect. must be less than the border width. don’t test it, bestie ⚠️
  • shod.snapProximity β€” the proximity of edges of a container in pixels for the snap attraction to occur when moving the container. if set to zero, no snap attraction occurs. the default is 8 pixels. magnetic behavior, lowkey πŸ”₯
  • shod.faceName β€” the font of the text in the title bar. title bar typography moment πŸŽ€
  • shod.foreground β€” the color of the text in the title bar. make it readable, make it cute πŸ’–
  • shod.titleWidth β€” the width of the title bar. give the title bar its space πŸ’…
  • shod.urgentBackground, shod.urgentTopShadowColor, and shod.urgentBottomShadowColor β€” the body color, light shadow color, and dark shadow color for the 3D effect of the borders and title bars of urgent windows. urgent window, urgent aesthetic 🚨

πŸͺŸ Window-dependent resources πŸͺŸ

these ones are client-specific, bestie β€” they’re named based on the class, name instance, and role of a window. so replace CLASS with the class of the window, NAME with the name of the instance of the window, and ROLE with the role of the window. periodt.

  • shod.CLASS.NAME.ROLE.type β€” define the type of a window matching the given class, name and role. possible values are NORMAL (for normal windows), DESKTOP (for desktop windows), DOCKAPP (for docked applications), or PROMPT (for prompt windows). categorize her πŸ’…
  • shod.CLASS.NAME.ROLE.state β€” define the initial state of a window matching the given class, name and role. its value should be a comma-separated list of states. possible states for normal windows are above, below, fullscreen, maximized, minimized, shaded, and sticky. possible states for dockapp windows are extend, and resized, and shrunk. state check ✨
  • shod.CLASS.NAME.ROLE.dockpos β€” define the position in the dock of a docked application matching the given class, name and role. its value should be a number, starting from position 1. dock order is real πŸŽ€
  • shod.CLASS.NAME.ROLE.desktop β€” define the number of the desktop to send the matching application to. unlike other window managers, shod counts desktop from 1; so the first desktop is desktop 1, not the desktop 0. no zero-index nonsense here, bestie πŸ¦‹

🌈 ENVIRONMENT 🌈

the following environment variables affect the execution of shod. very β€œyour environment matters” of it πŸ’œ

  • DISPLAY β€” the display to start shod on. where the magic happens πŸ–₯️
  • SHELL β€” the shell to run with exec(3). shell bestie 🐚

πŸ’€ BUGS πŸ’€

real talk: XSizeHints(3) are ignored. size hints make no sense in a tiled and tabbed window manager. they only make sense when the size of a single container depends only on a single window, and a single window dictates the size of a single container. when the size of a container depends on the size of other windows (as in the tiled situation), or when a set of windows must have the same size (as in the tabbed situation), it makes no sense to constrain the size of a container based on the size hints of a single window, because the relation from windows to containers is no more one-to-one. πŸ’€

shaped client-windows do not have shaped containers. they are mapped inside a rectangular container. rectangular era, I guess 🫠

the focus buttons and raise buttons settings, that were presented in earlier versions of shod, are removed in recent versions. it is also not possible anymore to have a focus-follow-pointer focus behavior. no cap, that’s gone πŸ™ˆ

that’s the whole page, bestie β€” SHOD(1), Debian source/version, dated September 10, 2022. go be iconic with your resources πŸ’…βœ¨

πŸ“¦ where this page comes from