DTWMRC(4)

πŸ“¦
version 2.5.3 Β· 2 versions
, in nixos 26.05

πŸ’– NAME πŸ’–

Okay bestie, this is dtwmrc(4) β€” the dtwm Window Manager Resource Description File. Yes, it's a special file, and yes, it's giving main character energy for your CDE desktop. πŸ’…

✨ DESCRIPTION ✨

The dtwmrc window manager is a supplementary resource file that controls much of the behavior of the CDE window manager dtwm. It contains descriptions of resources that cannot easily be written using standard X Window System, Version 11 resource syntax. The resource description file contains entries that are referred to by X resources in defaults files (for example, /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/app-defaults/$LANG/Dtwm) or in the RESOURCE_MANAGER property on the root window. For example, the resource description file enables you to specify different types of window menus; however, an X resource is used to specify which of these window menus the dtwm should use for a particular window. The specifications of the resource description file supported by the dtwm workspace manager are a strict superset of the specifications supported by the OSF Motif Window Manager (mwm 1.2.4). In other words, the system.mwmrc or $HOME/.mwmrc file that you've used for mwm is easily made usable by dtwm. To merge your personal mwm resource specifications into dtwm:

  • Copy either /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/etc/config/$LANG/sys.dtwmrc or /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/config/$LANG/sys.dtwmrc to $HOME/.dt/dtwmrc.
  • Use a text editor to move menu definitions, key bindings, and button bindings from your .mwmrc file to your dtwmrc file. To merge your key and button bindings, you'll need to augment the key and button bindings that are referenced by dtwm by default (refer to buttonBindings and keyBindings resources in the dtwm app-defaults file /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/app-defaults/$LANG/Dtwm). To replace the key or button bindings, you'll also need to modify your personal keyBindings and buttonBindings resources.
  • Restart dtwm.

πŸ“ Location πŸ“

The workspace manager searches for one of the following resource description files, where $LANG is the value of the language environment on a per-user basis:

  • $HOME/.dt/$LANG/dtwmrc
  • $HOME/.dt/dtwmrc
  • /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/etc/config/$LANG/sys.dtwmrc
  • /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/etc/config/sys.dtwmrc
  • /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/config/$LANG/sys.dtwmrc
  • /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/config/sys.dtwmrc

The first file found is the first used. If no file is found, a set of built-in specifications is used. A particular resource description file can be selected using the configFile resource. The following shows how a different resource description file can be specified from the command line:

/nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/bin/dtwm -xrm "Dtwm*configFile: mydtwmrc"

🧩 Resource Types 🧩

The following types of resources can be described in the dtwm resource description file:

  • Buttons β€” Workspace manager functions can be bound (associated) with button events.
  • Keys β€” Workspace manager functions can be bound (associated) with key press events.
  • Menus β€” Menu panes can be used for the window menu and other menus posted with key bindings and button bindings.

πŸ› οΈ DTWM RESOURCE DESCRIPTION FILE SYNTAX πŸ› οΈ

The dtwm resource description file is a standard text file that contains items of information separated by blanks, tabs, and new lines characters. Blank lines are ignored. Items or characters can be quoted to avoid special interpretation (for example, the comment character can be quoted to prevent it from being interpreted as the comment character). A quoted item can be contained in double quotes (" "). Single characters can be quoted by preceding them by the back-slash character (\fP), except for workspace names, which may contain no back-slash characters. If a line ends with a back-slash, the next line is considered a continuation of that line. All text from an unquoted # to the end of the line is regarded as a comment and is not interpreted as part of a resource description. If ! is the first character in a line, the line is regarded as a comment.

🌸 Workspace Manager Functions 🌸

Workspace manager functions can be accessed with button and key bindings, and with workspace manager menus. Functions are indicated as part of the specifications for button and key binding sets, and menu panes. The function specification has the following syntax:

function = function_name [function_args]
function_name = workspace manager function
function_args = {quoted_item | unquoted_item}

The following functions are supported. If a function is specified that isn't one of the supported functions then it is interpreted by dtwm as f.nop.

  • f.action β€” This function causes the specified action to be invoked by means of the message server.
  • f.beep β€” This function causes a beep.
  • f.circle_down [ icon | window] β€” This function causes the window or icon that is on the top of the window stack to be put on the bottom of the window stack (so that it is no longer obscuring any other window or icon). This function affects only those windows and icons that are obscuring other windows and icons, or that are obscured by other windows and icons. Secondary windows (that is, transient windows) are restacked with their associated primary window. Secondary windows always stay on top of the associated primary window and there can be no other primary windows between the secondary windows and their primary window. If an icon function argument is specified, then the function applies only to icons. If a window function argument is specified then the function applies only to windows.
  • f.circle_up [ icon | window] β€” This function raises the window or icon on the bottom of the window stack (so that it is not obscured by any other windows). This function affects only those windows and icons that are obscuring other windows and icons, or that are obscured by other windows and icons. Secondary windows (that is, transient windows) are restacked with their associated primary window. If an icon function argument is specified then the function applies only to icons. If an window function argument is specified then the function applies only to windows.
  • f.create_workspace β€” This function creates a new workspace. The new workspace name is generated automatically and is of the form ws_n where n is an integer.
  • f.delete_workspace β€” This function deletes the current workspace. Windows that reside only in this workspace will be moved to the next workspace. If the last workspace is being deleted, then windows will be moved to the first workspace.
  • f.exec command β€” the original line also has a weird little (or ! command)" 10 artifact and we're keeping it, bestie. This function causes command to be executed (using the value of the $MWMSHELL or $SHELL environment variable if set; otherwise, /usr/bin/sh ). The ! notation can be used in place of the f.exec function name.
  • f.focus_color β€” This function sets the colormap focus to a client window. If this function is done in a root context, then the default colormap (setup by the X Window System for the screen where dtwm is running) is installed and there is no specific client window colormap focus. This function is treated as f.nop if colormapFocusPolicy is not explicit.
  • f.focus_key β€” This function sets the keyboard input focus to a client window or icon. This function is treated as f.nop if keyboardFocusPolicy is not explicit or the function is executed in a root context.
  • f.goto_workspace workspace β€” This function causes the workspace manager to switch to the workspace named by workspace. If no workspace exists by the specified name, then no action occurs. Note that adding and deleting workspaces dynamically and affect this function.
  • f.help [topic [volume]] β€” again, the original page has a stray " 10 hanging out here, so we're preserving it. This function displays help on the specified topic and volume. If no volume is given, then the workspace manager volume is assumed. If no topic is given, then help on the front panel is shown.
  • f.help_mode β€” This function causes the workspace manager to enter into help mode. In help mode, the pointer changes shape to indicate that the window manager is waiting for you to select a front panel control. Any help defined for the control is then shown in a help window.
  • f.kill β€” This function is used to close application windows. The actual processing that occurs depends on the protocols that the application observes. The application lists the protocols it observes in the WM_PROTOCOLS property on its top level window. If the application observes the WM_DELETE_WINDOW protocol, it is sent a message that requests the window be deleted. If the application observes both WM_DELETE_WINDOW and WM_SAVE_YOURSELF, it is sent one message requesting the window be deleted and another message advising it to save its state. If the application observes only the WM_SAVE_YOURSELFprotocol , it is sent a message advising it to save its state. After a delay (specified by the resource quitTimeout), the application's connection to the X server is terminated. If the application observes neither of these protocols, its connection to the X server is terminated.
  • f.lower [- client | within | freeFamily] β€” okay so this one lowers a primary window to the bottom of the global window stack (where it obscures no other window) and lowers the secondary window (transient window or dialog box) within the client family. The arguments are mutually exclusive β€” pick one, bestie πŸ’…. The client argument indicates the name or class of a client to lower. The name or class of a client appears in the WM_CLASS property on the client's top-level window. If the client argument is not specified, the context that the function was invoked in indicates the window or icon to lower. Specifying within lowers the secondary window within the family (staying above the parent) but does not lower the client family in the global window stack. Specifying freeFamily lowers the window to the bottom of the global windows stack from its local family stack ✨.
  • f.marquee_selection β€” this function is only useful in conjunction with the CDE file manager (see dtfile(1)). It enables selection of file manager objects that have been placed on the root window. It must be bound to a button when used πŸ–±οΈ.
  • f.maximize β€” this function causes a client window to be displayed with its maximum size. Refer to the maximumClientSize, maximumMaximumSize, and limitResize resources in dtwm(1) πŸ‘‘.
  • f.menu menu_name β€” this function associates a cascading (pull-right) menu with a menu pane entry or a menu with a button or key binding. The menu_name function argument identifies the menu to be used πŸŽ€.
  • f.minimize β€” this function causes a client window to be minimized (iconified). When a window is minimized with no icon box in use, and if the lowerOnIconify resource has the value True (the default), the icon is placed on the bottom of the window stack (such that it obscures no other window). If an icon box is used, then the client's icon changes to its iconified form inside the icon box. Secondary windows (that is, transient windows) are minimized with their associated primary window. There is only one icon for a primary window and all its secondary windows πŸ¦‹.
  • f.move β€” this function initiates an interactive move of a client window 🫢.
  • f.next_cmap β€” this function installs the next colormap in the list of colormaps for the window with the colormap focus 🌈.
  • f.next_key [ icon | window | transient] β€” this function sets the keyboard input focus to the next window/icon in the set of windows/icons managed by the workspace manager (the ordering of this set is based on the stacking of windows on the screen). This function is treated as f.nop if keyboardFocusPolicy is not explicit. The keyboard input focus is only moved to windows that do not have an associated secondary window that is application modal. If the transient argument is specified, then transient (secondary) windows are traversed (otherwise, if only window is specified, traversal is done only to the last focused window in a transient group). If an icon function argument is specified, then the function applies only to icons. If a window function argument is specified, then the function applies only to windows ⌨️.
  • f.next_workspace β€” this function causes the workspace manager to switch to the next workspace. If the last workspace is currently active, then this function will switch to the first workspace πŸ”₯.
  • f.nop β€” this function does nothing. Iconic behavior, honestly πŸ’€.
  • f.normalize β€” this function causes a client window to be displayed with its normal size. Secondary windows (that is, transient windows) are placed in their normal state along with their associated primary window 🌸.
  • f.normalize_and_raise β€” this function causes a client window to be displayed with its normal size and raised to the top of the window stack. Secondary windows (that is, transient windows) are placed in their normal state along with their associated primary window ⭐.
  • f.occupy_all β€” this function causes the associated window to be placed in all workspaces 🧚.
  • f.pack_icons β€” this function is used to relayout icons (based on the layout policy being used) on the root window or in the icon box. In general this causes icons to be "packed" into the icon grid πŸŽ€.
  • f.pass_keys β€” this function is used to enable/disable (toggle) processing of key bindings for workspace manager functions. When it disables key binding processing all keys are passed on to the window with the keyboard input focus and no workspace manager functions are invoked. If the f.pass_keys function is invoked with a key binding to disable key binding processing the same key binding can be used to enable key binding processing πŸ”‘.
  • f.post_wmenu β€” this function is used to post the window menu. If a key is used to post the window menu and a window menu button is present, the window menu is automatically placed with its top-left corner at the bottom-left corner of the window menu button for the client window. If no window menu button is present, the window menu is placed at the top-left corner of the client window πŸ’….
  • f.prev_cmap β€” this function installs the previous colormap in the list of colormaps for the window with the colormap focus 🌈.
  • f.prev_key [ icon | window | transient] β€” this function sets the keyboard input focus to the previous window/icon in the set of windows/icons managed by the workspace manager (the ordering of this set is based on the stacking of windows on the screen). This function is treated as f.nop if keyboardFocusPolicy is not explicit. The keyboard input focus is only moved to windows that do not have an associated secondary window that is application modal. If the transient argument is specified, then transient (secondary) windows are traversed (otherwise, if only window is specified, traversal is done only to the last focused window in a transient group). If an icon function argument is specified then the function applies only to icons. If a window function argument is specified then the function applies only to windows ⌨️.
  • f.prev_workspace β€” this function causes the workspace manager to switch to the previous workspace. If the first workspace is currently active, then this function switches to the last workspace πŸ”₯.
  • f.quit_mwm β€” this function terminates dtwm (but NOT the X window system) πŸ’€.
  • f.raise [-client | within | freeFamily]" 10 β€” this function raises a primary window to the top of the global window stack (where it is obscured by no other window) and raises the secondary window (transient window or dialog box) within the client family. The arguments to this function are mutually exclusive. The client argument indicates the name or class of a client to lower. If the client is not specified, the context that the function was invoked in indicates the window or icon to lower. Specifying within raises the secondary window within the family but does not raise the client family in the global window stack. Specifying freeFamily raises the window to the top of its local family stack and raises the family to the top of the global window stack πŸ‘‘.
  • f.raise_lower [ within | freeFamily] β€” this function raises a primary window to the top of the global window stack if it is partially obscured by another window; otherwise, it lowers the window to the bottom of the window stack. The arguments to this function are mutually exclusive. Specifying within raises a secondary window within the family (staying above the parent window), if it is partially obscured by another window in the application's family; otherwise, it lowers the window to the bottom of the family stack. It has no effect on the global window stacking order. Specifying freeFamily raises the window to the top of its local family stack, if obscured by another window, and raises the family to the top of the global window stack; otherwise, it lowers the window to the bottom of its local family stack and lowers the family to the bottom of the global window stack πŸ¦‹.
  • f.refresh β€” this function causes all windows to be redrawn ✨.
  • f.refresh_win β€” this function causes a client window to be redrawn πŸ’–.
  • f.remove β€” this function causes a client window to be removed from the current workspace. If the client window exists only in this workspace, no action occurs 🫢.
  • f.resize β€” this function initiates an interactive resize of a client window πŸ“.
  • f.restore β€” this function restores the previous state of an icon's associated window. If a maximized window is iconified, then f.restore restores it to its maximized state. If a normal window is iconified, then f.restore restores it to its normalized state 🌸.
  • f.restore_and_raise β€” this function restores the previous state of an icon's associated window and raises the window to the top of the window stack. If a maximized window is iconified, then f.restore_and_raise restores it to its maximized state and raises it to the top of the window stack. If a normal window is iconified, then f.restore_and_raise restores it to its normalized state and raises it to the top of the window stack ⭐.
  • 2f.restart β€” this function causes dtwm to be restarted (effectively terminated and re-executed). Restart is necessary for dtwm to incorporate changes in both the dtwmrc file and X resources πŸ”„.

f.screen [ next | prev | back | screen_number]

Okay so this one warps the pointer to a specific screen number, or to the next, previous, or last visited (back) screen. The arguments are mutually exclusive β€” pick one, bestie, not all four πŸ’….

  • screen_number tells it which screen to warp the pointer to. Screens are numbered starting from screen 0.
  • next warps the pointer to the next managed screen, skipping over any unmanaged screens.
  • prev warps the pointer to the previous managed screen, skipping over any unmanaged screens.
  • back warps the pointer to the last visited screen.

f.send_msg message_number

This sends an XClientMessageEvent of type _MOTIF_WM_MESSAGES with message_type set to message_number ✨.

The client message is sent only if message_number is included in the client's _MOTIF_WM_MESSAGES property. Also: a menu item label gets grayed out if that menu item is used to do f.send_msg of a message that is not included in the client's _MOTIF_WM_MESSAGES property. So if your menu item looks muted, that's why 😭.


f.separator

This puts a menu separator in the menu pane at the specified location. The label is ignored β€” it's just here for the divider aesthetic πŸŽ€.


f.set_behavior

This makes the workspace manager restart with the default behavior β€” if a custom behavior is configured β€” or with a custom behavior β€” if a default behavior is configured. Flip-flop energy, honestly.

By default this is bound to Shift Ctrl Alt &<Key>!.


f.title

This inserts a title in the menu pane at the specified location. Menu glow-up unlocked πŸ‘‘.


f.toggle_frontpanel

If the front panel is in the normal state, this function causes it to be minimized. If the front panel is minimized, this function changes it back to the normal state. A little minimize/unminimize moment πŸ¦‹.


f.version

This causes the workspace manager to display its release version in a dialog box. Cute little "who am I" popup πŸ’–.


f.workspace_presence

This displays the workspace presence (or "Occupy Workspace") dialog box. This dialog lets you view and set the workspace in which a particular window resides.

The root context is disallowed for this function. Not available, not invited, no cap 🚫.

πŸŽ€ Function Constraints πŸŽ€

Each function may be constrained as to which resource types can specify the function (for example, menu pane) and also what context the function can be used in (for example, the function is done to the selected client window).

Function contexts are:

  • root β€” no client window or icon has been selected as an object for the function.
  • window β€” a client window has been selected as an object for the function. This includes the window's title bar and frame. Some functions are applied only when the window is in its normalized state (for example, f.maximize) or its maximized state (for example, f.normalize).
  • icon β€” an icon has been selected as an object for the function.

If a function is specified in a type of resource where it is not supported, or is invoked in a context that does not apply, then the function is treated as f.nop. Basically: wrong place, wrong vibe, it does nothing πŸ’€.

The following table indicates the resource types and function contexts in which workspace manager functions apply. (Table turned into a list because we're not doing markdown tables in this group chat, but every row is here, periodt.)

  • f.action β€” contexts: root, icon, window; resources: button, key, menu.
  • f.beep β€” contexts: root, icon, window; resources: button, key, menu.
  • f.circle_down β€” contexts: root, icon, window; resources: button, key, menu.
  • f.circle_up β€” contexts: root, icon, window; resources: button, key, menu.
  • f.create_workspace β€” contexts: root, icon, window; resources: button, key, menu.
  • f.delete_workspace β€” contexts: root, icon, window; resources: button, key, menu.
  • f.exec β€” contexts: root, icon, window; resources: button, key, menu.
  • f.focus_color β€” contexts: root, icon, window; resources: button, key, menu.
  • f.focus_key β€” contexts: root, icon, window; resources: button, key, menu.
  • f.goto_workspace β€” contexts: root, icon, window; resources: button, key, menu.
  • f.help β€” contexts: root, icon, window; resources: button, key, menu.
  • f.help_mode β€” contexts: root, icon, window; resources: button, key, menu.
  • f.kill β€” contexts: icon, window; resources: button, key, menu.
  • f.lower β€” contexts: root, icon, window; resources: button, key, menu.
  • f.marquee_selection β€” contexts: root; resources: button.
  • f.maximize β€” contexts: icon, window(normal); resources: button, key, menu.
  • f.menu β€” contexts: root, icon, window; resources: button, key, menu.
  • f.minimize β€” contexts: window; resources: button, key, menu.
  • f.move β€” contexts: icon, window; resources: button, key, menu.
  • f.next_cmap β€” contexts: root, icon, window; resources: button, key, menu.
  • f.next_key β€” contexts: root, icon, window; resources: button, key, menu.
  • f.next_workspace β€” contexts: root, icon, window; resources: button, key, menu.
  • f.nop β€” contexts: root, icon, window; resources: button, key, menu.
  • f.normalize β€” contexts: icon, window(maximized); resources: button, key, menu.
  • f.normalize_and_raise β€” contexts: icon, window; resources: button, key, menu.
  • f.occupy_all β€” contexts: icon, window; resources: button, key, menu.
  • f.pack_icons β€” contexts: root, icon, window; resources: button, key, menu.
  • f.pass_keys β€” contexts: root, icon, window; resources: button, key, menu.
  • f.post_wmenu β€” contexts: root, icon, window; resources: button, key.
  • f.prev_cmap β€” contexts: root, icon, window; resources: button, key, menu.
  • f.prev_key β€” contexts: root, icon, window; resources: button, key, menu.
  • f.prev_workspace β€” contexts: root, icon, window; resources: button, key, menu.
  • f.quit_dtwm β€” contexts: root; resources: button, key, menu (root only).
  • f.raise β€” contexts: root, icon, window; resources: button, key, menu.
  • f.raise_lower β€” contexts: icon, window; resources: button, key, menu.
  • f.refresh β€” contexts: root, icon, window; resources: button, key, menu.
  • f.refresh_win β€” contexts: window; resources: button, key, menu.
  • f.remove β€” contexts: root, icon, window; resources: button, key, menu.
  • f.resize β€” contexts: window; resources: button, key, menu.
  • f.restart β€” contexts: root; resources: button, key, menu (root only).
  • f.restore β€” contexts: icon, window; resources: button, key, menu.
  • f.restore_and_raise β€” contexts: icon, window; resources: button, key, menu.
  • f.screen β€” contexts: root, icon, window; resources: button, key, menu.
  • f.send_msg β€” contexts: icon, window; resources: button, key, menu.
  • f.separator β€” contexts: root, icon, window; resources: menu.
  • f.set_behavior β€” contexts: root, icon, window; resources: button, key, menu.
  • f.title β€” contexts: root, icon, window; resources: menu.
  • f.toggle_frontpanel β€” contexts: root, icon, window; resources: button, key, menu.
  • f.version β€” contexts: root, icon, window; resources: button, key, menu.
  • f.workspace_presence β€” contexts: window; resources: button, key, menu.

Also the raw troff table line is literally:

tgroup dispwid="6.09in"

🌈 WORKSPACE MANAGER EVENT SPECIFICATION 🌈

Events are indicated as part of the specifications for button and key binding sets, and menu panes.

Button events have the following syntax:

button =~[modifier_list ]&<button_event_name >
modifier_list =~modifier_name { modifier_name}

The following table indicates the values that can be used for modifier_name. Note that [Alt] and [Meta] can be used interchangeably on some hardware.

  • Ctrl β€” Control Key
  • Shift β€” Shift Key
  • Alt β€” Alt Key
  • Meta β€” Meta Key
  • Mod1 β€” Modifier1
  • Mod2 β€” Modifier2
  • Mod3 β€” Modifier3
  • Mod4 β€” Modifier4
  • Mod5 β€” Modifier5

Locking modifiers are ignored when processing button and key bindings. The following table lists keys that are interpreted as locking modifiers. The X server may map some of these symbols to the Mod1 - Mod5 modifier keys. These keys may or may not be available on your hardware:

  • Caps Lock
  • Shift Lock
  • Kana Lock
  • Num Lock
  • Scroll Lock

The following table indicates the values that can be used for button_event_name.

  • Btn1Down β€” Button 1 Press
  • Btn1Up β€” Button 1 Release
  • Btn1Click β€” Button 1 Press and Release
  • Btn1Click2 β€” Button 1 Double Click
  • Btn2Down β€” Button 2 Press
  • Btn2Up β€” Button 2 Release
  • Btn2Click β€” Button 2 Press and Release
  • Btn2Click2 β€” Button 2 Double Click
  • Btn3Down β€” Button 3 Press
  • Btn3Up β€” Button 3 Release
  • Btn3Click β€” Button 3 Press and Release
  • Btn3Click2 β€” Button 3 Double Click
  • Btn4Down β€” Button 4 Press
  • Btn4Up β€” Button 4 Release
  • Btn4Click β€” Button 4 Press and Release
  • Btn4Click2 β€” Button 4 Double Click
  • Btn5Down β€” Button 5 Press
  • Btn5Up β€” Button 5 Release
  • Btn5Click β€” Button 5 Press and Release
  • Btn5Click2 β€” Button 5 Double Click

Key events that are used by the workspace manager for menu mnemonics and for binding to workspace manager functions are single key presses; key releases are ignored. Key events have the following syntax:

key =~[modifier_list] <Key>key_name
modifier_list =~modifier_name { modifier_name}

All modifiers specified are interpreted as being exclusive β€” this means that only the specified modifiers can be present when the key event occurs. Modifiers for keys are the same as those that apply to buttons. The key_name is an X11 keysym name. Keysym names can be found in the keysymdef.h file (remove the XK_ prefix). Slay that keysym knowledge, bestie πŸ”₯.

πŸ’… BUTTON BINDINGS πŸ’…

Okay so the buttonBindings resource value is literally the name of a set of button bindings that configure workspace manager behavior, bestie. A workspace manager function can happen when a button press occurs with the pointer over a framed client window, an icon, or the root window. The context that says where the button press applies is also the context for invoking the workspace manager function when the button press is done β€” and yes, that matters for functions that are context sensitive πŸ‘€.

The button binding syntax is:

Buttons bindings_set_name
{
    button    context    function
    button    context    function
    ...
    button    context    function
}

The syntax for the context specification is:

context = object[| context]
object = root | icon | window | title | frame | border | app

The context specification tells you where the pointer must be for the button binding to be effective. For example, a context of window means the pointer must be over a client window or window management frame for the button binding to be effective. The frame context is for the window management frame around a client window β€” including the border and titlebar. The border context is for the border part of the window management frame, not including the titlebar. The title context is for the title area of the window management frame. And the app context is for the application window, not including the window management frame. If an f.nop function is specified for a button binding, the button binding is not done β€” periodt ✨.


πŸŽ€ KEY BINDINGS πŸŽ€

The keyBindings resource value is the name of a set of key bindings that configure workspace manager behavior. A window manager function can be done when a particular key is pressed. The context in which the key binding applies is indicated in the key binding specification. The valid contexts are the same as those that apply to button bindings. The key binding syntax is:

Keys bindings_set_name
{
    key    context    function
    key    context    function
    ...
    key    context    function
}

If an f.nop function is specified for a key binding, the key binding is not done. If an f.post_wmenu or f.menu function is bound to a key, dtwm automatically uses the same key for removing the menu from the screen after it has been popped up. The context specification syntax is the same as for button bindings with one addition: the context ifkey may be specified for binding keys that may not be available on all displays. If the key is not available and if ifkey is in the context, then reporting of the error message to the error log is suppressed. This feature is useful for networked, heterogeneous environments 🌐. For key bindings, the frame, title, border, and app contexts are equivalent to the window context. The context for a key event is the window or icon that has the keyboard input focus β€” or root if no window or icon has the keyboard input focus πŸ‘‘


Menus can be popped up using the f.post_wmenu and f.menu workspace manager functions. The context for workspace manager functions that are done from a menu is root, icon, or window depending on how the menu was popped up. In the case of the window menu or menus popped up with a key binding, the location of the keyboard input focus indicates the context. For menus popped up using a button binding, the context of the button binding is the context of the menu. The menu pane specification syntax is:

Menu menu_name
{
    label  [mnemonic]  [accelerator ]   function
    label  [mnemonic]  [accelerator ]   function
    ...
    label  [mnemonic]  [accelerator ]   function
}

Each line in the Menu specification identifies the label for a menu item and the function to be done if the menu item is selected. Optionally a menu button mnemonic and a menu button keyboard accelerator may be specified. Mnemonics are functional only when the menu is posted and keyboard traversal applies. The label may be a string or a bitmap file. The label specification has the following syntax:

label = text | bitmap_file
bitmap_file = @file_name
text = quoted_item | unquoted_item

The string encoding for labels must be compatible with the menu font that is used. Labels are greyed out for menu items that do the f.nop function or an invalid function or a function that doesn't apply in the current context. A mnemonic specification has the following syntax:

mnemonic = _ character

The first matching character in the label is underlined. If there is no matching character in the label, no mnemonic is registered with the workspace manager for that label. Although the character must exactly match a character in the label, the mnemonic does not execute if any modifier β€” such as Shift β€” is pressed with the character key. The accelerator specification is a key event specification with the same syntax as is used for key bindings to workspace manager functions βŒ¨οΈπŸ’–.


πŸ¦‹ INCLUDING FILES πŸ¦‹

You may include other files into your dtwmrc file by using the include construct. For example:

INCLUDE
{
    /usr/local/shared/dtwm.menus
    /home/kmt/personal/my.bindings
}

This causes the files named to be read in and interpreted in order as an additional part of the dtwmrc file. Include is a top-level construct. It cannot be nested inside another construct β€” no inception energy here, bestie πŸ™ˆ.


⚠️ WARNINGS ⚠️

Errors that occur during the processing of the resource description file are recorded in: $HOME/.dt/errorlog. Be sure to check this file if the appearance or behavior of dtwm is not what you expect. Lowkey the errorlog is your bestie when things get weird πŸ’€βœ¨.


πŸ“ FILES πŸ“

  • $HOME/.dt/$LANG/dtwmrc
  • $HOME/.dt/dtwmrc
  • /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/etc/config/$LANG/sys.dtwmrc
  • /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/etc/config/sys.dtwmrc
  • /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/config/$LANG/sys.dtwmrc
  • /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/config/sys.dtwmrc
  • $HOME/.dt/errorlog

dtwm(1), mwm(1), dtfile(1), X(1). Also the original page just says Caret at the end there β€” iconic mystery, we keep it exactly as is, no cap 🫢.


xoxo, your dtwmrc(special file) bestie β€” CDE 2.5.3 energy, date not printed on this page, still absolutely slaying πŸ’…βœ¨πŸŽ€

πŸ“¦ where this page comes from