HP-UX Virtual Partitions

By Marty Poniatowski

X, Motif, and CDE all use configuration files to shape their appearance and behavior. Elements of appearance and behavior such as foreground color, keyboard focus policy, and client decoration are resources that can be controlled by values in the appropriate configuration file. In X, Motif, and CDE, the word "resource" has a special meaning. It doesn't refer to vague natural resources or generic system resources, but to rather specific elements of appearance and behavior. Some examples are the foreground resource, the keyboardFocusPolicy resource, and the clientDecoration resource. For example, the foreground color could be black, keyboard focus policy could be explicit, and client decoration could be plus-title (title bar only). These would appear in some appropriate configuration file as the following:

• *foreground: black

• *keyboardFocusPolicy:explicit

• *clientDecoration: +title

Which configuration file these resources appear in depends on the scope of the effect desired (system-wide or individual user) and the graphical interface level being used (X, Motif, or CDE).

X Configuration Files

The X Window System has the following configuration files:

sys.x11start

sys.Xdefaults

system.mwmrc

X*screens

X*devices

X*pointerkey

By convention, these files are located in the /usr/lib/X11 directory; however, I have noticed that many systems have eliminated this directory and moved many of the X-related files elsewhere in the system. In addition, each X client application has its own app-defaults configuration file located, also by convention, in the /usr/lib/X11/app-defaults directory. Although six files are listed above, unless you're configuring a workstation for multiple-display screens (X*screens), multiple-input devices (X*devices), or keyboard-only pointer navigation (X*pointerkey), you'll typically need to work with only sys.x11start, sys.Xdefaults, and system.mwmrc.

The sys.x11start file was a script used to start X and X clients before the advent of CDE. System administrators or knowledgeable users modified sys.x11start so that the appropriate mix of X clients started "automatically." The sys.Xdefaults file was read as X started to obtain values for various appearance and behavior resources. Modifications to sys.Xdefaults ensured that the X environment and clients had the proper appearance and behavior. system.mwmrc contained the configuration of the Workspace menu and button and key bindings. system.mwmrc has been replaced by the Motif version also, system.mwmrc.

Motif Configuration Files

Motif added only one new configuration file to the X list: system.mwmrc.

By convention, this file is kept with the X configuration files in /usr/lib/X11. Actually, this file isn't new; it is the Motif version of system.mwmrc, which simply replaced system.mwmrc in Motif environments.

Whereas X brought network and interclient communication standards to the graphical user interface, Motif brought a standard for appearance and behavior, the standard originally defined in IBM's System Application Architecture Common User Access (SAACUA), which forms the basis of most PC-based GUIs. Thus, push buttons and scroll bars have a defined look and a defined behavior, and double-clicking always causes the default action to happen.

From a programmer's point of view, the Motif Widget Toolkit represents quite an advance over programming in "raw" X. From a user's or system administrator's point of view, the Motif user environment is about the same as the X environment, except that the mwm Window Manager is replaced with the Motif window manager.

CDE Configuration Files

It is possible to point to over 80 files that, in one way or another, contribute to configuring some aspect of CDE. By convention, these files reside in the /usr/dt directory. However, if you remove from this list such files as those that:

• Configure CDE applications as opposed to the environment itself

• Establish default actions and datatype definitions that, although you create your own definitions in separate files, you never modify

• Are CDE working files and should not be customized

• Are more appropriately associated with configuring the UNIX, X, and Motif environments underlying CDE, including the various shell environments, then CDE has approximately 19 configuration files, as shown in Table 14-1

Although 19 configuration files are still a lot, don't be alarmed by the number. You won't need to modify many of them, and can ignore a couple that you modify once and then forget. You need to understand in depth for periodic modification only one or two, perhaps a system-wide *.dt file for custom actions and datatypes or maybe dtwm.fp, if you are required to modify the front panel on a regular basis for some reason.

Still, configuring CDE is not something you want to start hacking at without a little preparation and a good idea of what you want to accomplish. All CDE configuration files are pretty well commented, so a good first step is to print the ones you want to modify.

Table 14-2 organizes CDE configuration files according to their content and the breadth of their influence:

.

The file sys.dtwmrc controls the configuration of the Workspace Manager at the system level. This includes all of the following:

Unlike configuration files for X or Motif, sys.dtwmrc does not control the following configuration elements:

Instead, to avoid a massively large and overly complex configuration file, these elements were separated into their own configuration file in CDE, dtwm.fp.

Some front panel configuration elements, like the number of workspaces and their arrangement in the workspace switch, are controlled through resources in a sys.resources, dt.resources, or .Xdefaults file. Like other Workspace Manager configuration files, sys.dtwmrc can be copied to a user's home directory, actually to $HOME/.dt/ as dtwmrc, and modified to personalize the user's environment beyond the system-wide configuration of sys.dtwmrc.

The sys.resources file is one of those files you might modify once, and then never again. The dt.resources file is one of those files you won't ever need to modify and can ignore. The .Xdefaults file is one you or your users may modify on occasion.

The sys.resources file is where you put any non-default resources that you want in effect when a brand new user logs into CDE for the very first time. For example, as system administrator, you may want your users to have a CDE front panel with prenamed workspaces, special colors, particular fonts, or application windows in certain locations. After the first-time login, sys.resources is ignored in favor of dt.resources. This file, dt.resources, resides in $HOME/.dt/sessions/current (or $HOME/.dt/sessions/home when the home session is restored) and is created automatically by CDE. You can consider it a CDE working file and forget about it. The .Xdefaults file is where you or an end-user would list X resources specific to the user's personal CDE environment. sys.resources, dt.resources, and .Xdefaults contain a list of resources and their values.

The sys.sessions file controls which clients start the very first time a new user logs into CDE. The dt.sessions file is to sys.sessions as dt.resources is to sys.resources.

It may be efficient to configure CDE to start particular applications for your users. You would specify these applications in sys.sessions. When a new user logs in for the first time, the CDE environment includes the specified clients. At the end of this first session by logging out, the remaining cli-ents would be recorded in $HOME/.dt/sessions/current for CDE ($HOME/.dt/sessions/home when the home session is restored).

The sys.dtprofile file is a template that is automatically copied at first login into each new user's home directory as .dtprofile. sys.dtprofile replaces .profile or .login in the CDE environment (although either .profile or .login can be sourced in .dtprofile by removing the # comment symbol in front of DTSOURCEPROFILE=true). The .dtprofile file holds the personal environment variables that would, in a character-based environment, be found in .profile or .login. Use .dtprofile to avoid the interference that terminal I/O commands cause to CDE's graphical environment.

The CDE login manager, dtlogin, presets the following environment variables to default values:

Variations to these default values belong in each user's .dtprofile. Additional environment variables can be added as needed to shape the user's environment to the needs of the work context. Just beware of using commands that cause any terminal I/O.

Like .dtprofile, Xsession is a shell script that sets user environment variables. The environment variables in Xsession apply system-wide. The environment variables in .dtprofile apply only to a user's personal environment. Furthermore, Because the login manager runs Xsession after the X server has started, the variables in Xsession are not available to the X server. Variables typically set in Xsession include the following:

As an example, suppose that you are the system administrator for several mixed workstation and X terminal clusters located at a single site. As usually happens, most users have grown accustomed to certain text editors. Some like vi, others prefer emacs, and a couple wouldn't be caught dead without dmx. An easy way to provide each user with his or her favored text editor would be to reset their EDITOR variable to the appropriate value in the individual .dtprofile files.

Xconfig contains resources that control the behavior of dtlogin and it also provides a place to specify the locations for any other dtlogin configuration files you create. The Xconfig file works on a system-wide basis, so it's one of those files that you modify only once and then forget about. When, during login, Xconfig is run, several CDE configuration files get referenced: Xaccess, Xservers, Xresources, Xstartup, Xsession, Xreset, and Xfailsafe. Like Xconfig itself, most of these files are the type that you modify once when installing CDE and then, unless the network topology changes, you never deal with again.

Xaccess, as the name implies, is a remote display access control file. Xaccess contains a list of the host names allowed or denied XDMCP connection access to the local computer. For example, when an X terminal requests login service, dtlogin consults the Xaccess file to determine whether service should be granted.

The primary use of the Xservers file is to list the display screens on the local system that dtlogin is responsible for managing. dtlogin reads the Xservers file and starts an X server for each display listed there. It then starts a child dtlogin process to manage the server and display the login screen. Note that dtlogin works only locally; dtlogin can't start an X server on a remote system or X terminal. For remote display servers, some other mechanism must be used to start the server, which then uses the X Display Management Control Protocol (XDMCP) to request a login screen from dtlogin.

The Xservers file is another of those files that you may spend some time with initially and then, unless the topology of your network changes, never deal with again. When do you use Xservers? When a display doesn't match the default configuration. The default configuration assumes that each system has a single bitmap display and is the system console. X terminals, multiple displays (heads), multiple screens, and Starbase applications all require configuration lines in the Xservers file.

The Xresources file contains the list of resources that control the appearance and behavior of the login screen. After you substitute your company's logo for the CDE logo and change the fonts and colors, you'll probably never have to deal with Xresources again (unless your company changes its logo).

Xstartup is a system-wide configuration file executed by the login manager, from which it receives several environment variables:

Because it can execute scripts and start clients on a system-wide basis, Xstartup is similar to sys.sessions. The difference is that Xstartup runs as root. Thus, modifications to Xstartup should be reserved for actions like mounting file systems.

Xreset is a system-wide companion script to Xstartup. It runs as root and essentially undoes what Xstartup put in motion.

The Xfailsafe file contains customizations to the standard failsafe session. The failsafe session provides a way to correct improper CDE sessions caused by errors in the login and session configuration files. As such, Xfailsafe is something that your users are not ever going to use, but you can make your life a little easier with a few judicious customizations.

The sessionetc file resides in a user's .dt/sessions directory and personalizes that user's CDE session. sessionetc handles the starting of additional X clients like sys.session, but on a per-user basis, as opposed to system-wide. Although dt.session also starts clients on a per-user basis, the clients are those of the default or current session. dt.session resides in .dt/ session/current. sessionetc, which resides in .dt/session, and should contain only those clients that are not automatically restored. Typically, these are clients that do not set the WM_COMMAND properly, so the session manager can't save or restore them; thus, they need to be restarted in sessionetc.

The sys.font file contains the system-wide, default session font configuration. These default fonts were based on usability studies, so sys.font is a file you may never change. However, should you encounter a situation that requires a different mix of fonts on a system-wide basis, this is where you'd change them. Note that the font resources and values mentioned in sys.font must match exactly the default font resources specified in the /usr/dt/appdefaults/C/Dtstyle file.

CDE has a bunch of files that specify CDE action and data type definitions. All these files end with the file extension *.dt. A*.dt ("dt" for "desk top") contains both data type and action definitions. The default *.dt files are in /usr/dt/appconfig/types/C and act on a system-wide basis. Similarly, user-prefs.dt, the master copy of which is also located in /usr/dt/appconfig/ types/C, is used at the personal user level.

The .Xauthority file is a user-specific configuration file containing authorization information needed by clients that require an authorization mechanism to connect to the server.

CDE Configuration File Locations

Where CDE looks for particular configuration files depends on the nature of the configuration files, principally what the files configure and how wide their influence is. Table 13-3 shows the location of system and user configuration files based on the nature of the file content.

For each of the default system-wide file locations listed in Table 14-3, a corresponding location exists for custom system-wide configuration files. These custom files should be located in the appropriate subdirectory under /etc/dt. The basic procedure is to copy the file you need to customize from /usr/dt/something to /etc/dt/something and then do your modifications there. For example, to change the default logo in Xresources, copy /usr/dt/ config/C/Xresources to /etc/dt/config/C/Xresources, open /etc/dt/config/ C/Xresources, and make your changes.

This is an important point. Files located under /usr/dt are considered CDE system files and will be overwritten during updates. Thus, any customizations you do there will be lost. Make all modifications to system-wide configuration files in /etc/dt and its subdirectories.

How Configuration Files Play Together

From the material covered so far, you've probably concluded correctly that CDE configuration files aren't something to go hacking at without a plan - a well-thought-out plan. You've probably figured out that the element you want to configure and the breadth of influence you want it to have determine which configuration file you modify.

For instance, if you wanted to set an environment variable, you have a choice of four configuration files: sys.dtprofile, Xconfig, Xsession, and .dtprofile. But if you want to set environment variables that affect only a particular user, your choice immediately narrows to a single file, .dtprofile.

Now the only remaining piece of the puzzle is to understand the order in which CDE reads its configuration files. When a configuration element (an environment variable, resource, action, or data type) is specified twice but with different values, you obviously want the correct value used and the incorrect value ignored.

The following rules apply:

• For environment variables, the last specified value is used.

• For resources, the last specified value is used. However, this is influenced by specificity. Thus, emacs*foreground takes precedence over just *foreground for emacs clients, regardless of the order in which the resources were encountered.

• For actions, the first specified is used.

• For data types, the first specified is used.

Table 14-4 illustrates which specification is used when CDE reads multiple specifications of configuration elements in its configuration files:

Put in terms of scope, a user configuration file overrides a system-wide configuration file. Looking at the order of precedence of just system-wide configuration files, the files in /etc/dt have precedence over those in /usr/dt, so global custom configurations have precedence over the CDE default configuration. And $HOME/.dt files take precedence over those in /etc/dt.

For resources, the elements used to specify a GUI's appearance and behavior, CDE sets values according to the following priorities:

1. Command line - When you start a client from the command line, options listed on the command line have top priority.

2. Xresources, .Xdefaults, dt.resources, sys.resources, - When CDE starts, it reads these resource configuration files to determine the value of X resources to use for the session.

3. RESOURCE MANAGER - Resources already in the property RESOURCE_MANAGER may affect an application that is just starting.

4. app-defaults - Specifies "default" resource values that differ from built-in resource values.

5. built-in defaults - Default resources that are "hard-coded" have the lowest priority.

Specific resource specifications take precedence over general resource specifications. For example, suppose that you want a certain font in your text entry areas. You could correctly specify a *FontList resource in your personal .Xdefaults file, only to have it overwritten by an *XmText*FontList in an app-defaults file. Although app-defaults is of lower priority than .Xdefaults, the resource specification set there is more specific, so it takes precedence.

For environment variables, CDE sets values according to the following priorities:

1. $HOME/.dtprofile - User-specific variables have top priority.

2. /etc/dt/config/C/Xsession - Custom system-wide variables not read by X server.

3. /etc/dt/config/C/Xconfig - Custom system-wide variables read by X server.

4. /usr/dt/config/C/Xsession - Default system-wide variables not read by X server.

5. /usr/dt/config/C/Xconfig - Default system-wide variables read by X server.

6. /usr/dt/bin/dtlogin - Built-in default variables have the lowest priority.

For data type and action definitions, CDE looks for .dt files according to the following priority:

1. $HOME/.dt/types

2. /etc/dt/appconfig/types/C

3. /usr/dt/appconfig/types/C

Remember that for data types or actions, the first value that it finds is the one it uses. So if you just can't get a file type or action to work, check for a duplicate entry earlier in the file or for an entry in a file with higher priority. Note also that the environment variable DTDATABASESEARCHPATH can be set either in /etc/dt/config/Xsession or $HOME/.dtprofile, to add directories where CDE can search for file type and action definition information.

Specifying Appearance and Behavior

You need to know only two tricks to specifying appearance and behavior resources in configuration files. The first is to specify the resource and its value correctly. The second is to specify the resource and value in the correct configuration file.

Two caveats involve colors and fonts. The CDE style manager provides a graphical interface for modifying colors and fonts. However, if you specify an application's color or font directly, this specification will override the ability of the style manager to manage that resource for the application.

Typical ways to specify a color or font directly include the following:

• Type the specification on the command line as a startup option.

• Include the specification in the application's app-defaults file.

• Use the xrdb utility to add resources for the application to the resource database.