DTSESSION(1)

📦
version 2.5.3 · 2 versions
, in nixos 26.05

🎀 dtsession — NAME 🎀

okay so welcome to dtsession(user cmd), bestie 💅 this page is literally all about dtsession — the CDE Session Manager, and it's the ✨main character✨ of your entire desktop life. she runs the whole "hello you're logged in → okay bye you're logged out" era and keeps every app's vibe intact. buckle up, this one's a long one 🦋

✨ SYNOPSIS ✨

dtsession [-norestore] [-session session_name]

that's it. that's the whole launch ritual. two flags. iconic. 👑

💖 DESCRIPTION 💖

The dtsession client gives you X11R6 XSMP-compliant session management (and, by proxy, ICCCM 1.1-compliant session management too) during a user session — and a "user session" just means the stretch of time from login to logout. that's the whole window. 🌸

what does she actually do, you ask? glad you asked:

  • she launches a window manager (yes, the actual WM — she's the plug 🔌)
  • she lets you save a session, restore a session, lock a session
  • she launches screen savers
  • she allocates colors for desktop-compatible clients

not her being the entire infrastructure or whatever 💀

👑 Key Supported Tasks

the dtsession client supports these key tasks, and ngl it's a list:

  • Initializing a session.
  • Launching a window manager.
  • Restoring a home, current, display-specific home, or display-specific current session.
  • Providing session locking on command or timeout.
  • Providing session screen saving on command or timeout.
  • Acting as a color allocation server for other DT clients.
  • Saving a home, current, display-specific home, or display-specific current session.
  • Displaying confirmation dialog at logout.
  • Displaying session selection dialog at logout.
  • Terminating a session.

like she does everything. periodt. 💅

🦋 A Session

so what even is a session? a session is the collection of applications, settings and resources that are present on the user's desktop. simple as that. ✨

session management is a set of conventions and protocols that let a special session manager (hi, that's dtsession 🫶) save and restore a user's session. the dream is: you log into your system and get presented with the exact same set of running applications, settings and resources that were there when you logged off. nothing moved. nothing changed. immaculate continuity.

when a user logs into the desktop for the very first time, a default initial (new user) session is loaded. afterward, dtsession supports the notion of a current, a home, and a display-specific session — and a display-specific one may be either current or home. iykyk 💜

🌱 The Initial Session

first login ever? when a user logs into the desktop for the first time, dtsession will generate the user's initial session using system default values. 🐣

the initial session is sometimes referred to as the "new user" session" — okay not the extra quote, it's the "new user" session. refer to Session Resource Management and Session Application Management for more info. (one of those is further down this very page, stay tuned 👀)

🔥 The Current Session

the user's running session is always considered the current session — no cap. whether it got restored upon login from a saved home session, a saved current session, or the system default initial session, it's current. that's just how she is.

based on the user's Style Manager Startup settings, when the user exits the session, the current session is automatically saved. 😭 so thoughtful. then when the user next logs into the desktop, dtsession lets the user select that previously saved current session as the session to start. meaning: the desktop gets restored to the same state it was in when the user last logged out. the way that works is genuinely so satisfying.

🏠 The Home Session

other option, other vibe: have the desktop restored to the same state every single time the user logs in, regardless of what state it was in when the user logged out. frozen in time. 🧊✨

the user may save the state of the current session, then — via the Style Manager Startup settings — have the desktop start that session every time the user logs in. alternatively, dtsession will let the user select the home session as the session to start at login. either route, you land in the same cozy place. 🎀

🖥️ Display-specific Sessions

want a specific session for a specific display? bestie, you can have a display-specific session, it's not a myth.

to do this, copy the $HOME/.dt/sessions directory to the $HOME/.dt/sessions/display directory, where display is the real, unqualified hostname. and listen — pablo:0 is valid, pablo.gato.com:0 or local:0 is not. them's the rules. 🙈

when the user logs in, dtsession will let them select a display-specific home or current session as the session to start. Dtsession will actually launch the session only if it is compatible with the user's login display. so yes she gatekeeps a little, but for good reason 💅

📜 The X11R6 XSMP Session Management Protocol

okay this is the big one. for an application to be saved upon logout and restarted upon login, it has to participate in a simple session management protocol, and dtsession supports the X11R6 XSMP Session Management Protocol. 🔥

applications that wish to save their state can take part in the WM_SAVE_YOURSELF protocol. to do this, an application needs to set the WM_SAVE_YOURSELF property on one and only one of its top-level windows. (one! not two! she checks! 👀)

when the user presses the Set Home Session button in the Style Manager, dtsession sends a SaveYourself message to the top-level window of each of its clients. that message sets the save-type to Local, shutdown to 0, interact-style to None and fast to 0.

when an application receives the message, it sends a SaveYourselfPhase2Request message to the Session Manager, which will reply with a SaveYourselfPhase2 message. only when the Window Manager receives the SaveYourselfPhase2 message will it save its state. the information saved by the Window Manager for each of its client's set of windows will include: geometry, icon state and workspace. ✨

if interact-style on the initial SaveYourself message is None, the application cannot interact with the user in any way while it's saving its state. if it's Any, the application can interact with the user for any purpose — including de-iconifying itself and changing its current workspace. 🪟

to minimize confusion, the Session Manager issues a ToolTalk message to the Window Manager requesting the recommended order to interact. the Window Manager responds with the list of SM_CLIENT_IDs and their associated workspace numbers, in workspace order. after receiving an Interact message (with interact-style set to Any), an application should go system-modal to prevent other, less well-behaved non-interacting applications from allowing user interaction while the application is interacting with its user. yes, she's asking everyone to be considerate. the audacity of the badly behaved apps, honestly 😭

because an application will usually save its state into a file, the Session Manager provides DtSessionSavePath as a convenience function that returns a full pathname of a file in which an application can save its state. while the application is saving its state, dtsession awaits notice from the application that it's done. to tell dtsession that the state save is complete, the application updates the WM_COMMAND property on its top-level window. 🫶

the WM_COMMAND property on an application's top-level window serves two purposes:

  1. a change of this property is the indication to dtsession that an application is done saving its state, and dtsession can proceed to the next application.
  2. the WM_COMMAND property value is expected to contain the command line that dtsession will use to restart the application at session startup.

if an application is launched with a full pathname, then it should use the full pathname when setting WM_COMMAND. applications that don't need to save their state but still want to be restarted can simply set WM_COMMAND during application startup and forget about it. set it and forget it, that's the energy ⭐

refer to the XmAddWmProtocols, XmAddWMProtocolCallback, and XSetCommand APIs for more information.

in addition to the "save-yourself" client session management support, the X11R6 XSMP protocol provides the following features (and these are not found in the ICCCM protocol, so like, enjoy):

  • It allows applications to interact with the user during normal shut down to confirm or discard unsaved changes.
  • It provides a mechanism to explicitly tell applications to exit.
  • Most importantly, it provides a common framework to support applications that are not X clients and applications that exit before the session is saved but that must remain part of the session for restart purposes (for example, an input method server).

that last one is genuinely such an underrated flex 💜

🫶 The ICCCM Session Management Protocol

dtsession implements the X11R6 XSMP session management protocol and provides backward compatibility by acting as a proxy for client applications that continue to use the older ICCCM session management protocol. both eras welcome at her table. 🌈

🌈 Restoring A Session

at session startup time, dtsession presents a dialog that lets the user select which of the following sessions to start:

  • Current — Start the user's most recent session.
  • Home — Start the user's home session.
  • display-name - Current — Create a new display-specific session and start the first of the following sessions that exists:
    1. display-specific Home
    2. generic Home
    3. new user (initial) session
  • display-name - Home — Create a new display-specific session and start the user's generic home session if it exists. Otherwise, start a new user session.
  • Fail-safe Session — Start a fail-safe session (Xfailsafe).

although a user's list of sessions isn't known until after the user logs in, the dialog presents all of the session choices. (she's manifesting your sessions before they exist, that's just her thing ✨)

if a user selects a session that doesn't exist, dtsession takes the following actions. if the user selects:

  • Home — dtsession starts a new user session.
  • Current — dtsession starts the user's home session if it exists. if it does not, it starts a new user session.

if the user selects a display-specific session and one does not exist, dtsession posts a warning dialog stating that a new session will be created. the warning dialog contains three buttons:

  • Cancel Login — Cancels the login and returns the user to the login screen.
  • OK — If a display-specific Home session was selected, dtsession creates a new display-specific session and starts the user's generic home session if it exists. If it does not exist, it starts a new user session.

If a display-specific Current session was selected, dtsession creates a new display-specific session and starts a display-specific home, generic home, or new user session, depending on which it finds first.

  • Help — Displays help text about the warning dialog.

three buttons, three paths, no ambiguity. she's organized like that 🎀

🎨 Session Resource Management

the session manager uses the X Server RESOURCE_MANAGER property on which to make available desktop resources to all applications. 🌈 the session manager will load the RESOURCE_MANAGER in the following manner:

  • load the system default resources, AND
  • merge any system administrator specified resources, AND
  • merge any user specified resources.

(and yes, the ANDs are load-bearing, they're literally in caps in the original, respect them 💅)

the desktop default resources can be found in /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/config/$LANG/sys.resources. these resources will be made available to each user's session via the RESOURCE_MANAGER property.

🚨 do NOT edit this file, bestie. it should not be edited as it will be unconditionally overwritten upon subsequent desktop installations. your edits will vanish into the void and you'll be sad. i'm warning you out of love 😭🫶

Okay so system admins can totally level up the system default resources by creating this file, bestie:

/nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/etc/config/$LANG/sys.resources

In that file, a system administrator can override system default resources or add extra ones. And because this file gets merged into the desktop default resources during session startup, it’s preferable to put only new or updated resource specs in there — not a whole copy of the desktop default resource file, okay? Resources specified here get made available to each user’s session through the RESOURCE_MANAGER property, and they take precedence over the desktop default resource file. Slay.

A user can also augment the desktop default and system administrator resources via their $HOME/.Xdefaults file. Resources in this file are made available to only that user’s session via the RESOURCE_MANAGER property, and they take precedence over the desktop default or system administrator resource files. Periodt.

Note: The X Toolkit Intrinsics specifies that it will load resources for an application from either RESOURCE_MANAGER or from $HOME/.Xdefaults, but not both. Ordinarily, that would mean the user’s $HOME/.Xdefaults file would be ignored. However, the session manager accommodates $HOME/.Xdefaults by merging it into the RESOURCE_MANAGER at session startup as described above. If a user changes $HOME/.Xdefaults, those changes will not be visible to new applications until the user invokes the ReloadResources action. 💅

The ReloadResources action tells the session manager to reload the RESOURCE_MANAGER with the system, system administrator, and user specified resources. It’s useful for making changes to system administrator or user specified resource files available to new applications. Fr fr.

See also dtresourcesfile(4) and dtsessionaction(5).

🫶 Session Application Management 🫶

At session startup, the session manager restarts any applications that were saved as part of the session. The system default set of applications to be restored as part of the user’s Initial Session lives here:

/nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/config/$LANG/sys.session

Do not edit this file — it will be unconditionally overwritten upon subsequent desktop installations. Not me warning you twice. 😭

See also dtsessionfile(4).

A system administrator may replace the set of applications restored as part of the user’s Initial Session by creating a file named:

/nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/etc/config/$LANG/sys.session

Unlike the resource files, this one is used as a complete replacement for the desktop default file — so yes, it is valid to make a copy of the system default file and make any necessary modifications. Iconic behavior, honestly.

🔐 Session Manager Authentication 🔐

The Session Manager uses ICE-based authentication as described in the Inter-Client Exchange (ICE) Library v1.0. It’s built with a table of available authentication protocols, and selection of the protocol is done via the AuthName resource.

The AuthName default is the string MIT-MAGIC-COOKIE-1. The Session Manager supports the same protocols as the Login Manager. No cap.

🪟 The Window Manager 🪟

dtsession is responsible for starting the window manager. By default, this one gets started:

/nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/bin/dtwm

An alternate window manager can be specified with the wmStartupCommand resource. Refer to the Workspace Manager specification for more information. 🦋

🎨 The Style Manager 🎨

The style manager provides the interface by which a user can change various desktop and X server settings for the current session. Refer to the Style Manager specification for more information. It’s giving customization, and we love that.

🌈 The Color Server 🌈

dtsession serves as the color server for the desktop and provides a set of resources that can be used to configure it, bestie. Let’s vibe check them:

  • The foregroundColor resource controls whether a pixel is allocated for the foreground color.
  • The dynamicColor resource specifies whether read-only colors are allocated.
  • The shadowPixmaps resource specifies whether colors are allocated for top shadow or bottom shadow.
  • The colorUse resource limits color allocation.
  • Finally, the writeXrdbColors resource specifies whether the *background and *foreground resources are placed in the resource database.

See the Color Server Resources section for more information. ✨

💅 The Color Sharing Protocol 💅

The CDE desktop makes use of a color sharing protocol between dtsession and the rest of the desktop (dtstyle in particular) and Motif. This protocol allows:

  • Non-CDE (non Motif/XmColorObject) applications to make use of the CDE color scheme.
  • Applications (Motif or not) that create their own private colormap to copy the dtsession desktop pixels and avoid or limit technicolor effect.
  • Motif applications to easily share the desktop GUI pixels when they use a private colormap.

The color sharing protocol involves:

  • The selection name (CUSTOMIZE_DATA), type (TYPE_OF_MONITOR), and format used by dtsession to communicate the monitor characterization to dtstyle (or any other style manager).
  • The selection name (CUSTOMIZE_DATA), type (PIXEL_SET), and format used by dtsession to communicate its palette pixel ids to the ColorObject (in libXm) and to dtstyle.
  • Two functions (XmeGetColorObjData and XmeGetColorObjCells) that deliver the desktop pixels to the application in a form easily suitable for its use (XColor).

A Color Set is a set of five colors that are used to represent a single logical color in the Motif toolkit. For each background color (the logical color), there are associated top shadow, bottom shadow, foreground, and select colors, all generated from the background color. These associated colors are the mechanism for giving widgets their 3-D appearance. Obsessed with the little 3-D moment.

A Color Palette is a named set of a maximum of eight background colors. A single palette is used to color the desktop components. A list of default palettes is provided from which the user can select. The user can also add and delete palettes, as well as modify an existing palette. Main character energy for real.

dtsession, the color server, uses ICCCM X Selection based mechanisms to communicate color use, palette and color set pixel information to the desktop clients.

The name of the (CUSTOMIZE_DATA) selection is the atom Customize Data:i, where i is the screen number.

The names of the targets are the atoms Type Of Monitor and Pixel Sets.

🦋 Type of Monitor Target 🦋

The Type Of Monitor target is used to convey color settings to the desktop clients, such as dtstyle or the Motif toolkit, that need this information. The content corresponds to the value of the dtsession color usage resources.

When asked to convert the screen Customize Data:i selection to the target Type Of Monitor, the format and content encoding used is the following:

  • type: STRING
  • length: 20
  • format: 8
  • content: a series of 4 numbers, in hexadecimal format, separated by the underscore (_) character (that is, using the printf/scanf format %x_%x_%x_%x), and including from left to right:
    • The colorUse resource, which corresponds to the type of monitor in use by the desktop.
      • B_W = 0
      • LOW_COLOR = 1
      • MEDIUM_COLOR = 2
      • HIGH_COLOR = 3
    • The shadowPixmaps resource, which controls if dithered pixmaps are used to render the shadows in the target GUI.
      • FALSE = 0
      • TRUE = 1
    • The foregroundColor resource, which controls whether or not a pixel was allocated for the foreground or if WhitePixel or BlackPixel is used.
      • DYNAMIC = 0
      • BLACK = 1
      • WHITE = 2
    • The dynamicColor resource, which controls whether or not the pixels allocated are read/write or read-only cells.
      • FALSE = 0
      • TRUE = 1

This information, especially dynamicColor, is currently used only by dtstyle in CDE to implement the color manager GUI. Iykyk.

🍓 Pixel Sets Target 🍓

The Pixel Sets target is used to convey palette and color set pixel information to the desktop clients. The content is always 8 color set values, but depending on the color usage settings, some entries will be duplicated. For the receiver of this information, however, it simply means it can access the index as specified in the high color scheme.

When asked to convert the screen Customize Data:i selection to the target Pixel Sets, the format used is the following:

  • type: STRING
  • length: 400
  • format: 8
  • content: a first number (%x_) for the colorUse resource (see “Type of Monitor Target” above for encoding) and a series of 8 (corresponding to the maximum number of color sets in CDE) sets of 5 numbers, in hexadecimal format (%x_%x_%x_%x_%x), each describing from left to right:
    • background pixel (bg)
    • foreground pixel (fg)
    • top_shadow pixel (ts)
    • bottom_shadow pixel (bs)
    • select_color pixel (sc)

The mapping between color set Ids and colorUse is as follows:

  • HIGH_COLOR
    • 3. Active window borders.
    • 4. Inactive window borders.
    • 5. Switch for workspace 1 and every fourth additional workspace (workspace 5, 9,...).
    • 6. Text and list areas.
    • 7. Main window background (primaryColorSetId) and switch for workspace 4 and every fourth additional workspace (workspace 8, 12,...).
    • 8. Dialog box background and menu bar (secondaryColorSetId) and switch for workspace 3 and every fourth additional workspace (workspace 7, 11,...).
    • 9. Switch for workspace 2 and every fourth additional workspace (workspace 6, 10, ...).
    • 10. Front panel background.
  • MEDIUM_COLOR
    • 11. Active window borders.
    • 12. Window bodies:
      • Inactive window borders
      • Main window and dialog box backgrounds and menu bar
      • Front Panel background
    • 13. Workspace switches and backgrounds
    • 14. Text and list backgrounds 🌸
  1. same as 2
  2. same as 2
  3. same as 3
  4. same as 2
  • LOW_COLOR and BLACK_WHITE — bestie this is the short stack, and here's how it breaks down:
    1. Active window borders.
    2. Everything else.
    3. .. to 8: same as 2.

Okay so for each color set, the cell allocation scheme is Literally This (and dynamicColor is what decides whether the pixels get allocated read/write or read-only — big mood, very important):

  • HIGH_COLOR · shadowPixmaps FALSE · foreground DYNAMIC · cells (fg,bg,ts,bs,sc) · number 5*8 = 40
  • HIGH_COLOR · shadowPixmaps FALSE · foreground BLACK or WHITE · cells (bg,ts,bs,sc) · number 4*8 = 32
  • HIGH_COLOR · shadowPixmaps TRUE · foreground DYNAMIC · cells (fg,bg,sc) · number 3*8 = 24
  • HIGH_COLOR · shadowPixmaps TRUE · foreground BLACK or WHITE · cells (bg,sc) · number 2*8 = 16
  • MEDIUM_COLOR · shadowPixmaps FALSE · foreground DYNAMIC · cells (fg,bg,ts,bs,sc) · number 5*4 = 20
  • MEDIUM_COLOR · shadowPixmaps FALSE · foreground BLACK or WHITE · cells (bg,ts,bs,sc) · number 4*4 = 16
  • MEDIUM_COLOR · shadowPixmaps TRUE · foreground DYNAMIC · cells (fg,bg,sc) · number 3*4 = 12
  • MEDIUM_COLOR · shadowPixmaps TRUE · foreground BLACK or WHITE · cells (bg,sc) · number 2*4 = 8
  • LOW_COLOR · shadowPixmaps FALSE · foreground DYNAMIC · cells (fg,bg,ts,bs,sc) · number 5*2 = 10
  • LOW_COLOR · shadowPixmaps FALSE · foreground BLACK or WHITE · cells (bg,ts,bs,sc) · number 4*2 = 8
  • LOW_COLOR · shadowPixmaps TRUE · foreground DYNAMIC · cells (fg,bg,sc) · number 3*2 = 6
  • LOW_COLOR · shadowPixmaps TRUE · foreground BLACK or WHITE · cells (bg,sc) · number 2*2 = 4
  • B_W · shadowPixmaps TRUE · foreground opposite · cells BG · number 0

🔒 Session Lock

Dtsession provides session locking, and honestly? Iconic security behavior. You can lock the current session directly by pressing the lock icon on the front panel. And if the X server supports it, the current session can also be locked after a specified period of inactivity ✨. To unlock the session, the user must enter their login password — no shortcuts, no vibes-only entry, actual password. 💅

By default, dtsession supports traditional local UNIX authentication for unlocking the session. Additional re-authentication functions — like the ones DCE requires — may be added by individual vendors.

🖼️ Screen Savers

Dtsession provides support for launching external screen savers as part of session locking from the front panel, or — if the X server supports it — after a specified period of inactivity. For the deets on how screen savers get integrated into the desktop, refer to the Screen Saver specification. 🎀

🖥️ X Server Screen Saver Extensions

Real talk: dtsession's ability to provide session lock or screen saver launch after a specified period of inactivity depends on whether an X server screen saver extension is even available. dtsession supports two such extensions:

  • X Consortium Sample X11 Screen Saver Extension 1.0
  • HP X Screen Saver Extension

The ability of dtsession to recognize both, either or none of these extensions is vendor specific. (So like… ask your vendor, bestie. 😭)

🚀 Launching The Session Manager

dtsession should be launched from the Xsession script. Xsession is described in the login manager specification. It's recommended that Xsession be launched from dtlogin as part of the login sequence as the default — but there are alternative methods of starting Xsession:

  • dtlogin — the default dtlogin configuration launches Xsession when a user logs in
  • proxy — some systems will allow programs such as xinit, x11start or startx to start Xsession

🧚 Starting Services Before the Session Manager

If you must start a service after login but before the Session Manager (for example, an input method server — very much a thing), start the service by placing a script in the fdirectory /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/config/Xsession.d.

To avoid being restarted by the Session Manager when a session is started, a service that must be started before the Session Manager should explicitly set the RestartStyleHint property to RestartNever (possibly by setting an Xt resource). This is the "please do not perceive me" setting, fr fr.

✨ OPTIONS ✨

The dtsession client is automatically invoked by the DT Login Manager (dtlogin). But if you want, dtsession may also be started on an existing X server. Heads up though: dtsession automatically starts a window manager. 👑

The following options are available:

  • -norestore — Instructs dtsession not to restore a previous session, and also not to save the session upon logout. Fresh start energy only. 🌸
  • -session session_name — Instructs dtsession to start the specified session. Valid session names are:
    • current
    • home
    • display_name:display_number /current
    • display_name:display_number /home

where display_name is the unqualified display host name and display_number is the display number. 🦋

🏁 RETURN

Exit values are:

  • 0 — Successful completion. Slay. 💖
  • >1 — Error condition occurred. Not slay. 💀

🍓 EXAMPLES

dtsession -norestore

Start session manager from command line without restoring previous session. No baggage, no old tabs open, just vibes. ✨

✨ RESOURCES ✨

Okay bestie, this is the part where you get to customize everything. Each resource has a Name, a Class, a Type, and a Default — I'm listing them all below so nothing gets lost, no cap. 💅

🎨 Color Server

  • colorUse — class ColorUse, type String, default DEFAULT
  • dynamicColor — class DynamicColor, type Boolean, default True
  • foregroundColor — class ForegroundColor, type String, default DYNAMIC
  • shadowPixmaps — class ShadowPixmaps, type String, default DEFAULT
  • writeXrdbColors — class WriteXrdbColors, type Boolean, default True

🔒 Screen Lock/Screen Save

  • keys — class Keys, type unsigned char, default NULL
  • passwordTimeout — class passwordTimeout, type unsigned int, default 10

🧚 Miscellaneous

  • AuthName — class AuthName, type String, default DEFAULT
  • IgnoreEnvironment — class IgnoreEnvironment, type String, default NULL
  • queryServerSettings — class QueryServerSettings, type Boolean, default False
  • NumSessionsBackedup — class NumSessionsBackedup, type unsigned int, default 2
  • saveFontPath — class SaveFontPath, type Boolean, default False
  • wmStartupCommand — class WmStartupCommand, type executable path, default NULL
  • tgroup dispwid="5.87in" — yes queen, that's literally how it's printed 💀

🔐 AuthName

This resource tells dtsession which authentication protocol to use. The default is the string MIT-MAGIC-COOKIE-1. And fun fact: dtsession supports the exact same protocols as dtlogin. 🫶

🌈 colorUse - DEFAULT

This one sets how many colors the user interface gets to use. Valid types are: the color server figures out the monitor type by peeping the number of display planes on the screen, like so:

  • 1,2 → B_W
  • 4 → LOW_COLOR
  • 6 → MEDIUM_COLOR
  • 7+ → HIGH_COLOR
  • B_W — a black and white system, bestie. The color palettes use two color cells for the UI. In this setup only two palettes exist: BlackWhite and WhiteBlack. These palettes cannot dynamically change — to switch a palette, every app using it has to be restarted. This value forces ShadowPixmaps to True, and ForegroundColor to either black or white depending on which palette you picked.
  • LOW_COLOR — a low color system. The palettes get two color sets and use a max of 12 color cells for the UI, including black and white (color cells 0 and 1). The number of co ShadowPixmaps and ForegroundColor. (Not me, that's literally what the page says 😭)
  • MEDIUM_COLOR — a medium color system. The palettes get 4 color sets and use a max of 22 color cells for the UI, including black and white (color cells 0 and 1). You can shrink the number of color cells by using the resources ShadowPixmaps and ForegroundColor.
  • HIGH_COLOR — a high color system. The palettes get 8 color sets and use a max of 42 color cells for the UI, including black and white (color cells 0 and 1). Again, the cell count can be reduced with ShadowPixmaps and ForegroundColor.

🦋 dynamicColor

Values: True or False. This one exists purely to reduce how many color cells get used up. Once you've picked a palette and you're not planning to switch it, set dynamicColor to False — iconic efficiency move. If it's False, colors cannot be dynamically changed using the DT style manager, and the palette you selected takes effect the next session. Next time the session comes up, the color server uses Read Only color cells that all clients can share, which means fewer color cells overall. Slay. ✨

🌸 foregroundColor

Values: White, Black, or Dynamic. ForegroundColor makes all text (that's the foreground, babe) use either pixel 0 or 1 (Black or White), or gives the foreground its own dedicated color cell that reacts to the background color (Dynamic) for each ColorSet. If you set it to White or Black, the number of color cells used per ColorSet drops by 1. Less is more, periodt.

🔑 keys

This is a list of the keyholders who can unlock the screen any time the user locks it. It's a list of user ids, separated by commas. Say user kim has this resource active during a session:

Dtsession*keys: fred,keith

Then fred and keith both have the power to unlock the display whenever kim locks it. Main character energy for everyone involved. 👑

⏳ passwordTimeout

Sets (in seconds) how long before the password dialog bounces off the screen. When the display is locked, the pointer shows a lock cursor and a dialog pops up asking for the user password. If there's zero pointer or keyboard activity for passwordTimeout seconds, the dialog is removed. It comes right back the moment any pointer or keyboard event is detected. A passwordTimeout of 0 leaves the password dialog in place for the entire time the display is locked. Default value: 10 seconds.

🧐 queryServerSettings

This decides whether dtsession queries the server at logout for all its settings, or only saves the settings that were set using the DT Style Manager. Querying the server guarantees everything gets saved — but ngl, there's a performance hit when a full query happens. Default is False, which means the server will not be queried.

💾 NumSessionsBackedup

Sets how many checkpoints to keep. When a session's checkpoint count goes over this value, the DiscardCommand properties for the oldest session get executed and the oldest checkpoint is removed. Default: 2.

🎀 shadowPixmaps

For color systems, values are True or False. If True, topShadowColor and bottomShadowColor use the same pixel as background, and topShadowPixmap and bottomShadowPixmap are specified instead of a solid color to create that 3D look. This cuts the number of color cells per ColorSet by 2. ShadowPixmaps defaults to True on systems with 4 or fewer color planes (16 or fewer color cells), and False on systems with more than 4 color planes.

🪟 wmStartupCommand

Lets you start an alternate window manager at login. If this resource is NULL, dtsession starts /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/bin/dtwm. An alternate startup might look like:

Dtsession*wmStartupCommand: /usr/bin/X11/mwm
Note: the command should not have any commands to a shell in it, and it should not be surrounded by quotes. Also, if you use any window manager other than dtwm, clients will be restored — but they may not be restored to the correct position. By default, this resource contains a NULL value. 🙈

📁 FILES 📁

  • /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/config/$LANG/sys.session — the desktop default set of applications for the user's Initial Session.
  • /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/etc/config/$LANG/sys.session — the System Administrator specified set of applications for the user's Initial Session.
  • /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/config/$LANG/sys.resources — the desktop default resources.
  • $HOME/.dt/startlog — a log of processes started by the Xsession script. This file is used only to help diagnose session startup problems.
  • $HOME/.dt/session/session_name/db.session — the CDE1.0 database file maintained for each session.
  • $HOME/.dt/sessionlogs — when dtsession is started by the Xsession script, its stderr is duplicated to a session-specific file in $HOME/.dt/sessionlogs, so all stderr written by apps started by dtsession gets logged in this file. The name of the file used is host_name_DISPLAY=$DISPLAY, where host_name is the name of the host where the session was started.
  • $HOME/.dt/session_dir/session_name/dtsession.db — the CDEnext database file maintained for each session, where session_dir is sessions or the display name for display-specific, and session_name is either home or current. CDEnext session databases supersede CDE1.0 session databases. Upgrade era, honestly. 💅
  • /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/etc/config/$LANG/sys.resources — system administrator specified resources.
  • $HOME/.Xdefaults — user specified resources.

Also, bestie, Dtsession stores session information in $HOME/.dt/sessions or $HOME/.dt/sessions/display. The content of these directories should not be directly edited by the user. Hands off the database, bestie. 🚫

  • /nix/store/6waxpwr8lzfzc9ka48gl7yh60rqvlkdb-cde-2.5.3/app-defaults/$LANG/Dtsession — default dtsession resources.

👀 SEE 👀

Go check out these related specs, iykyk:

  • dtstyle — Customization of many session properties
  • dtscreen — Desktop screen savers
  • dtwm — Window manager
  • dtlogin — Login manager
  • dtsessionaction — Session manager actions
  • dtsessiondb — Format and location of CDEnext session database files
  • dtsessionfile — Format and location of CDE 1.0 desktop session files
  • dtresourcesfile — Format and location of desktop resource files
  • startlog — Log of processes started by the Xsession script

And that's the whole page, bestie! 🎉 This one signs off as dtsession(user cmd) — so go forth and customize responsibly. Mwah! 💖✨🎀

📦 where this page comes from