SHOD(1)
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,shodignore 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 invokingshodwith the-ccommand-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'sriolists 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 toN.-y Nβ Set the position on the Y axis toN.-w Nβ Set the width of the container toN.-h Nβ Set the height of the container toN.
π 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 from1, not from0.
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:
- Window state.
- Window desktop.
- Window geometry (size and position).
- ID of the container the window is on.
- ID of the row the window is on.
- ID of the window.
- 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:
- An βyβ indicates that the window's container is sticky.
- An βMβ indicates that the window's container is maximized.
- An βmβ indicates that the window's container is minimized.
- An βfβ indicates that the window's container is fullscreen.
- An βsβ indicates that the window's container is shaded.
- An βaβ indicates that the window's container is above others. An βbβ indicates that the window's container is below others.
- 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.
- 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 from1, not from0.
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):
- The bottom layer (for containers below others).
- The middle layer (for normal containers).
- The upper layer (for containers above others).
- 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.
π Menus π
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, andshod.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, andshod.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,WorS) says which edge of the monitor β East, North, West or South β to align the dock to. the optional second letter (E,N,W,S,CorF) says which corner of that edge of the monitor to align the dock to; aCmeans the dock should be centered on that edge, and anFmeans the dock should be stretched to fill that edge. if no second letter is supplied, the dock is centered on that edge. for example, withNE, a horizontal dock will be placed in the north edge of the monitor, aligned to the northeast corner. and withEF, 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 to64(the size of most dockapps). tiny dock, big personality πshod.inactiveBackground,shod.inactiveTopShadowColor, andshod.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 is10desktops 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 ofNEwill 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 is8pixels. 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, andshod.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 areNORMAL(for normal windows),DESKTOP(for desktop windows),DOCKAPP(for docked applications), orPROMPT(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 areabove,below,fullscreen,maximized,minimized,shaded, andsticky. possible states for dockapp windows areextend, andresized, andshrunk. 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 position1. 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 from1; so the first desktop is desktop1, not the desktop0. 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 withexec(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
- nixos 26.05: shod 2.6.2
- nixpkgs unstable: shod 2.6.2
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms