HP OpenVMS Systems Documentation

It is usually best if applications use the default colors and allow the desktop to manage the colors consistently for all applications. However, this isn't always possible. If an application is not an OSF/Motif application running against the new version of the Motif library, it will not be able to take advantage of the new dynamic color model. Also, if color resources are explicitly defined, then shared dynamic colors will not be used. These applications should be able to coexist, but some undesired effects could occur if a palette is selected that conflicts with predefined colors in an application.

An application may exhibit "antisocial" color behavior---that is, it modifies colormap entries that it has not allocated for its own use. If these are desktop dynamic color entries, it will affect all applications. You may need to reselect the current palette in Style Manager to reset the colors properly.

Conflicting colors can make text hard to read or even invisible. They can also make it appear as if a control has disappeared from the application interface. Such effects are caused by the foreground color of an application control being set to a color similar to its background color, such as a white foreground on a white background.

Session Manager provides a number of resources that can be used to affect the foreground and background colors of the desktop. Also, many applications provide resources for setting the foreground and background colors. However, the simplest way to resolve these problems may be to select a different palette in Style Manager (or to use the Modify... dialog box to change the current palette).

To change any Session Manager resource, copy its application defaults file to the DECW$USER_DEFAULTS directory, as shown in the following example:

$ COPY CDE$SYSTEM_DEFAULTS:[APP-DEFAULTS.C]DTSESSION.DAT -
_$ DECW$USER_DEFAULTS:DTSESSION.DAT

Add or modify the resource strings in this file, exit the New Desktop, and log in again to restart Session Manager. By default, Session Manager loads the foreground and background resources each time the user logs in. This is due to the following default resource of Session Manager:

dtsession*writeXrdbColors: true

The foreground and background colors are determined dynamically from the colors in the user's selected palette. This is due to the following two default resources of Session Manager:

dtsession*dynamicColor: true
dtsession*foregroundColor: "DYNAMIC"

The *dynamicColor resource controls whether colors can be changed dynamically when you change palettes. The *foregroundColor resource controls whether the *foreground resource is set explicitly to either "BLACK" or "WHITE" or whether it is calculated based on the current palette. If "DYNAMIC" is used, the following resource controls the threshold above which the *foreground resource is set to white:

*foregroundThreshold: 70

which is specified in the file:

CDE$SYSTEM_DEFAULTS:[APP-DEFAULTS.C]DT.DAT

You can change the foreground color in an application from black or white to another color by adding a foreground resource specification to its application resource file. Since the default foreground resource specification is defined in its most general form, any application-specific foreground resource specification will override it. For example:

DECW$TERMINAL.main.terminal.foreground: goldenrod

overrides

*foreground: #FFFFFFFFFFFF (White)

In this example, the color goldenrod is applied to the foreground of all DECterms created after this change. The foreground of all other applications remains white.

3.7 Using the New Desktop Fonts

Fonts used by applications within the New Desktop are referenced by generic font names. These font names are not the names of actual fonts but rather are the names of font aliases. These aliases are mapped to real font names by means of font alias files. When the New Desktop login process starts, it selects the appropriate font alias files based on the current language selected and the resolution of the display. The New Desktop instructs the X server to which it is connected to reset its font path to include the new font directories. This operation is possible only if the login process is running on the same system as the X server. The login process determines whether this is the case by looking at the display node name and the current transport type.

For remote displays, New Desktop fonts are used only if the New Desktop font aliases are defined for the remote display.

3.7.1 Changing Application Font Size

With Style Manager's Font option, you can select the size of fonts used for all CDE applications. Your selection affects every CDE application that you start after you make the change, but it does not affect any CDE applications that are already running. Furthermore, the font size option does not affect any existing DECwindows applications.

3.8 Using X Terminals and Other Remote Displays

When using the New Desktop with remote displays such as X terminals, you need to give special consideration to certain components, including window managers and font aliases.

3.8.1 Selecting the New Desktop Window Manager

Most X terminals provide some local capabilities, including a local window manager that runs on the X terminal itself. The Workspace (Window) Manager provided with the New Desktop is an integral part of the New Desktop and must be used in order for the New Desktop to operate properly. Most local window managers for X terminals can yield to a remote window manager when it starts up. However, this feature is sometimes not the default option.

For example, the Digital VXT 2000 X Terminal provides the Allow Remote Window Manager option, but it is not the default. To use the New Desktop Window Manager, you must enable the Allow Remote Window Manager option, which is under the Customize option in the Terminal Manager... dialog box. For an equivalent option on other X terminals, consult your X terminal documentation.

3.8.2 Accessing Font Aliases

For X terminals and in any environment where the X server is not running on the local system, the font path is not modified to include the New Desktop font alias directories during the login process. As a result, the X server does not recognize the font names used with any of the New Desktop applications. Most applications use the same fallback font, and you will not be able to modify its size through the use of Style Manager's font option. Applications will run properly, but the size and font style of many of the applications will not be what you expect.

To avoid this problem, you need to make the New Desktop font aliases available to the X server. One way to do this is to use a font server running on a UNIX system. If the UNIX system supports the Common Desktop Environment (CDE), then the correct font aliases should be in place. If not, the font alias files can be copied from the OpenVMS Alpha system to the UNIX system. For the default C locale, the font alias files are:

CDE$SYSTEM_DEFAULTS:[CONFIG.XFONTS.C.100DPI]DECW$FONT_ALIAS.DAT
CDE$SYSTEM_DEFAULTS:[CONFIG.XFONTS.C.75DPI]DECW$FONT_ALIAS.DAT
CDE$SYSTEM_DEFAULTS:[CONFIG.XFONTS.C]DECW$FONT_ALIAS.DAT

Each of these files should be copied to appropriate font alias directories on the UNIX system and renamed to fonts.alias. See your UNIX X server and font server documentation for details on how modify font paths if necessary. Once the font server recognizes the New Desktop font aliases, add the font server to the X terminal or remote system's default font path.

For other languages, the font alias files are:

CDE$SYSTEM_DEFAULTS:[CONFIG.XFONTS.language.100DPI]DECW$FONT_ALIAS.DAT
CDE$SYSTEM_DEFAULTS:[CONFIG.XFONTS.language.75DPI]DECW$FONT_ALIAS.DAT

For non-C languages, always include the C locale font aliases after the language-specific font aliases.

If you do not have access to a font server, you may be able to include the font alias files directly in the font path of the X terminal or remote X server. You do this by copying the necessary font alias files to a location accessible by the remote system's X server. If the remote X server is running on an OpenVMS Alpha system, the correct locations for font alias files are:

SYS$COMMON:[SYSFONT.DECW.USER_100DPI]
SYS$COMMON:[SYSFONT.DECW.USER_75DPI]
SYS$COMMON:[SYSFONT.DECW.USER_COMMON]

After copying the font alias files, you need to reset the font path. You can do this by simply logging out of your session and then logging back in.

With remote displays, the font path is not dynamically changed at login time to include the font alias files for the selected language. Each time you change languages, you must edit the font path of the X terminal or remote display.

3.9 Using Multiple Screens

The New Desktop supports a single X display with multiple screens. This configuration is sometimes called a dual-headed display. For information about creating and managing multiple screens, see Appendix B.

3.10 Managing Processes Created Within the New Desktop

The New Desktop consists of many applications. Most of these applications are started implicitly on your behalf as detached processes. Most process state information, such as process logical names and global symbols, is not passed to detached processes. Usually only the DECW$DISPLAY and LANG logicals are passed. You can pass additional process logical names with a special symbol, or you can specify that subprocesses be created instead of detached processes.

3.10.1 Passing Process Logical Names to Detached Processes

If you require that additional process logical names be passed to detached processes, you can use a special mechanism within the New Desktop. This mechanism works using the symbol CDE$DETACHED_LOGICALS, which you define in your private applications setup file, SYS$MANAGER:DECW$PRIVATE_APPS_SETUP.COM. For example, the following definition causes the logical name MYLOGICAL to be passed to all created detached processes:

$ CDE$DETACHED_LOGICALS == "MYLOGICAL"

You can specify that all processes be created as spawned subprocesses instead of detached processes by defining the symbol CDE$SPAWN_PROCESSES in SYS$MANAGER:DECW$PRIVATE_APPS_SETUP.COM. The following definition causes all processes to be created as subprocesses:

$ CDE$SPAWN_PROCESSES == "TRUE"

Certain process quotas are shared by a process and all of its subprocesses. Specifying the creation of subprocesses may require that you increase some of your process quotas using the Authorize utility. In particular, PRCLM, PGFLQUOTA, and BYTLM may need to be increased.

3.10.3 Debugging Processes

You may want to display the actual DCL commands used to invoke each process in the New Desktop for debugging purposes. By defining the following symbol, you can capture this information in your error log file:

$ CDE$LOG_PROCESSES = "TRUE"

By default, this information is not captured in your error log file. Note that this information may significantly increase the size of your error log file if you are iteratively creating processes, for example, if you have selected multiple screen savers with a short time per background.

3.10.4 Identifying Processes By Name

Both the New Desktop and the DECwindows desktop have a well-defined naming strategy for the processes they create. You can see a list of processes on your system by using either the SHOW SYSTEM command or the SHOW USERS/FULL command.

The processes created within and specific to the New Desktop are shown in Table 3-7.

The processes created within and specific to the DECwindows desktop are shown in Table 3-8.

Some processes share the same name under both desktops, as shown in Table 3-9.

For more detailed information, see the related online help and the online CDE manual Common Desktop Environment: Advanced User's and System Administrator's Guide. For instructions on how to access this manual on line or obtain a printed copy, see Table 1-2.