[an error occurred while processing this directive]

HP OpenVMS Systems Documentation

Content starts here Getting Started With the New Desktop

Getting Started With the New Desktop


Previous Contents Index

5.8 Screen Savers

You can create additional screen savers for the New Desktop. An example screen saver is provided in CDE$SYSTEM_DEFAULTS:[EXAMPLES.DTSCREEN].

Creating a screen saver involves the following steps:

  1. Create a screen saver application.
  2. Create an action to invoke the screen saver application.
  3. Add the new screen saver action to the list of available screen savers. This is done by adding the following line to your SYS$MANAGER:DECW$PRIVATE_APPS_SETUP.COM file:


    DTSCREENSAVERLIST == "SampleScreenSaver"
    

    Use spaces to separate screen saver names in the list.
  4. Restart your session.

After completing these steps, the new screen saver appears in the list of available screen savers in the Screen option of Style Manager.

For more information about creating new screen savers, see the README. file in the examples directory.

5.9 Header Files

Header files for the CDE components, shown in Table 5-5, are supplied with the New Desktop. They enable application developers to take advantage of the Desktop APIs (drag and drop, save and restore, Workspace Manager, and so forth), Help services, and custom widgets.

The header files are in the DECW$INCLUDE directory. They are referenced in the source files of the examples directory with the following syntax:


#include <DT/filename.H>

where DT is a logical name that is defined as DECW$INCLUDE.

Note

Include must be specified in lowercase, and the brackets surrounding the include phrase must be angle brackets.

Table 5-5 CDE Header Files
File Function
Desktop Services APIs
DT/ACTION.H Action-related structures and functions
DT/DND.H Drag-and-drop functions
DT/DT.H CDE version information, DtInitialize, and DtAppInitialize functions
DT/DTS.H Data typing constants and functions
DT/SAVER.H Screen saver API functions
DT/SESSION.H Session Manager API (save and restore) functions
DT/WSM.H Workspace Manager API related data and functions
Help Services
DT/HELP.H Define functions for dtfile help
DT/HELPQUICKD.H Quick Help dialog resources and functions
Custom Widgets (available in libdtwidget.exe)
DT/COMBOBOX.H For combo box widget
DT/EDITOR.H For editor widget
DT/MENUBUTTON.H For menu button widget
DT/SPINBOX.H For spin box widget

5.10 CDE Example Programs

Several CDE example programs are included in the New Desktop and are described in Table 5-6. The example programs show how to use the various CDE APIs and other programming resources provided with the New Desktop. Each example directory contains a readme file (README.) that describes the example programs and a command file (nnnn.com) that can be used to build the example programs for that directory.

The top-level example directory can be referenced by using the CDE$EXAMPLES logical, as shown in the following example:


$ DIR CDE$EXAMPLES

 Directory CDE$SYSTEM_DEFAULTS:[EXAMPLES]

 DTACTION.DIR;1      DTDTS.DIR;1         DTHELP.DIR;1
 DTSCREEN.DIR;1      DTSESSION.DIR;1     DTWIDGET.DIR;1
 DTWSM.DIR;1

The header files for these example programs are included in the form:


#include <DT/filename.H>

where DT is a logical that is defined as DECW$INCLUDE.

Table 5-6 CDE Example Programs
Name Purpose
DTACTION Shows the use of the action API to invoke actions on a file. The application displays two text entry fields. Enter an action name in the first field and the name of the file to which the action is to be applied in the second field; then press Return.
DTDND Demonstrates how to use the drag-and-drop functions so that an application can be moved by dragging and dropping its icon. The example program consists of a row of three different sources for text, file name, and application-named data drags. It also has a type-in field that can accept either text or file name drops and a data area that accepts file-name or data drops.
DTDTS Demonstrates the use of the Dts data typing API. This program displays the data type, icon name, and supported actions for each file passed to it. The dtaction client can be used to execute a supported action on the file.
DTHELP Illustrates the use of the CDE help system's HelpTag language and the building of a CDE help file. You can invoke the Help Viewer to display the compiled help file (HELPDEMO.SDL).
DTSCREEN Contains an example program (SCREENSAVER.EXE) of the screen saver API. It is an example of a simple screen saver that uses the screen saver API and certain techniques to make the screen saver available to all desktop users or your own session. (Alternatively, you can select a screen saver from the set provided with the New Desktop for use in desktop sessions. You can preview and select these screen savers from the Style Manager Screen dialog box.)
DTSESSION Demonstrates the session mechanism and API. The program SESSION.EXE is an example of an application that supports the Dt session management protocol using the DtSession API. The application saves its current state (the value of a toggle button) when the session is terminated. When the session is restarted, the state of the toggle button is restored. (For more information about save and restore, see Section 5.3.)
DTWIDGET Contains demonstrations of the widget library. The CONTROLS.EXE program demonstrates DtSpinBox, DtComboBox and DtMenuButton controls. The EDITOR.EXE program demonstrates the DtEditor widget.
DTWSM Contains demonstrations of the Workspace Manager API. The OCCUPY.EXE program demonstrates how to set and query an application's presence in CDE workspaces. The WSINFO.EXE program demonstrates how to query for information about the attributes of an application's current workspace.

5.11 CDE Programming Documentation

The CDE programming documentation includes the CDE help system with context-sensitive help, online CDE manuals, and online reference pages (also known as manpages). Printed CDE manuals are also available.

5.11.1 CDE Programming Manuals

The following CDE programming manuals are available on line:

  • Common Desktop Environment: Programmer's Overview
  • Common Desktop Environment: Programmer's Guide
  • Common Desktop Environment: Help System Author's and Programmer's Guide
  • Common Desktop Environment: Internationalization Programmer's Guide
  • Common Desktop Environment: Style Guide and Certification Checklist

For instructions on how to access these manuals or obtain printed copies, see Table 1-2.

5.11.2 Reference Pages

CDE reference pages (manpages) are provided on the kit as an installation option. Some of the commands described in the reference pages are not implemented in the New Desktop.

The reference pages are divided into sections. On OpenVMS Alpha, the file extension is used to indicate the section type, as shown in Table 5-7.

Table 5-7 Reference Page Sections
Section Section Type Section Number1
1 Applications filename.1
3 Libraries/programming filename.3
4 Programming filename.4
5 Include file formats filename.5

1A reference page section of .2, which applies to CDE system calls, does not exist in the New Desktop.

For instructions on how to access the reference pages, see Table 1-2.


Appendix A
New Desktop and CDE Differences

This appendix describes the most significant differences between the New Desktop on OpenVMS Alpha and CDE on UNIX systems. The New Desktop provides an environment that looks similar to any CDE environment, except for several components that are not included on OpenVMS Alpha (see Table 5-1).

The differences between the common components are primarily due to differences in the operating systems. For example, the file name syntax is different, and logical names are used by the New Desktop in place of environment variables.

A.1 Overall Differences

File names are always displayed and accepted in OpenVMS syntax. However, UNIX path specifications can be used as input to any New Desktop application. For example, /sys$manager/login.com is equivalent to SYS$MANAGER:LOGIN.COM.

Some CDE files are expected to appear in multiple places on UNIX systems through the use of symbolic links. With the New Desktop, files only appear in a single location. There is no dtappintegrate application to create symbolic links in the system directories for application-specific files residing in application-specific directory trees. New application files must be placed in the CDE$USER_DEFAULTS:[*...] system directory.

File names on OpenVMS are case insensitive. When a file name is used in other contexts, such as in the name of an action used to match an action (stub) file or in the description resource names for palettes and backdrops, the reference to the file name must be lowercase.

A.2 Login Manager Differences

Although the user interface for the login process is basically the same on the New Desktop as on CDE, the implementation of the Login Manager dtlogin on OpenVMS Alpha is different. The main differences are:

  • Login Manager on OpenVMS can manage only a single X display. Login Manager does not create a separate subprocess to manage its display, and the Login Manager process exits once the user logs in.
  • The New Desktop does not provide a chooser application to select alternate systems on which to run your session.
  • The New Desktop does not provide a Login Manager image. Instead, the shareable image CDE$SYSTEM_DEFAULTS:[BIN]DECW$LOGINOUT.EXE is dynamically activated by SYS$SYSTEM:DECW$LOGINOUT.EXE, the OpenVMS login process. A DECwindows or New Desktop login is initiated by the command RUN SYS$SYSTEM:DECW$STARTLOGIN.
  • Some of the scripts used with CDE, including Xsetup, Xstartup, Xreset, and dtprofile, are not supported in the New Desktop. Instead, custom configuration information is defined in the SYS$MANAGER:DECW$PRIVATE_APPS_SETUP.COM and SYS$MANAGER:DECW$PRIVATE_SERVER_SETUP.COM procedures.
  • In the New Desktop, most systemwide environment variables are supported as logical names. However, the user variants of the CDE environment variables (XMUSER* and DTUSER*) are not supported.
  • The login transitional greeting application, dthello, which displays "Starting the New Desktop for OpenVMS" when you log in, is started directly from dtlogin, not from the Xsession script. Command line arguments can not be passed to dthello.
  • In the New Desktop, the login log file is optionally enabled using the SYS$MANAGER:DECW$PRIVATE_APPS_SETUP.COM file (see Section 3.5). It does not use the Dtlogin.errorLogFile resource in the /usr/dt/config resource file.
  • The session startup log file is SYS$LOGIN:DECW$SM.LOG in the New Desktop, not $HOME/.dt/startlog.

The New Desktop login process does use an XSESSION.COM file to start the dtsession process, and the New Desktop does support an CDE$SYSTEM_DEFAULTS:[BIN.XSESSION_D] directory for processing specialized startup command files. In addition, the New Desktop supports the standard set of resource files, including their localized versions.

A.3 File Manager Differences

The OpenVMS implementation of File Manager differs from the UNIX implementation in the following areas:

  • File versions
    File versions do not exist on UNIX systems. On OpenVMS Alpha systems, you can choose to see all versions of your files or only the highest version. You can purge files by first selecting them and then choosing Purge from the Selected menu. Regardless of which version of a file name you selected, all versions of the file will be purged.
  • Protection dialog boxes
    Additional protection codes are available on OpenVMS systems.
  • Updating views of directories
    On UNIX systems, directories that are modified are automatically updated. On OpenVMS Alpha systems, a view of a directory is automatically updated if the directory is revised by a File Manager action, such as moving, deleting, or copying a file. To see whether directory changes were made by another process, you can select the Update option from the View menu.
  • On OpenVMS Alpha systems, there is nothing equivalent to a root directory.
    You cannot traverse from one disk or rooted logical to another.
  • Minimal use of extra processes
    UNIX implementations of File Manager make extensive use of additional (forked) processes. The OpenVMS implementation uses additional processes only for certain file system operations. Because of this, certain operations, such as directory updates, require the user to wait for completion rather than perform another action.

A.4 Printing Differences

The New Desktop printing implementation differs from the CDE printing implementation. The current implementation of CDE printing relies heavily on the UNIX line printer command, lp(1), and the line printer daemon, lpd(8), for its underlying functionality. Because the printing environment for CDE has not been standardized, it was not practical to port this type of operating system specific implementation to OpenVMS Alpha.

On OpenVMS Alpha, the New Desktop printing environment consists of a new application called Print Dialog. It uses the User Interface Language (UIL) and the DECwindows Print Widget (part of the DECWindows Extensions to Motif library) to provide access to printing on OpenVMS Alpha.

Although the New Desktop implementation differs, an attempt was made to integrate OpenVMS Alpha printing with the CDE printing paradigm so that printing would "feel" similar to printing on UNIX systems running CDE. Printers are still managed as objects on the desktop, with print jobs initiated either by dragging file icons and dropping them on printer icons or by selecting them and using the Print Dialog dialog box.

The Print Dialog executable file is located with the other New Desktop executables in the following directory:


CDE$SYSTEM_DEFAULTS:[BIN]PRINTDIALOG.EXE

A.5 Messaging Differences

Messaging capabilities of the New Desktop are more limited than those of CDE. Some activities that appear synchronous with CDE on UNIX are not synchronous in the New Desktop or may require user intervention. This limitation is noticeable in the following cases:

  • The timing of the busy light on the Front Panel and the hourglass cursor may be different with the New Desktop.
  • As described in Section A.3, file updates may not occur automatically.
  • When you invoke the Icon Editor from the Create Action application and edit an icon file, the edits that you make are not automatically shown in the displayed icon when you exit from Icon Editor, as they are with CDE on UNIX (see Section 4.1.6).
  • On the New Desktop, the Text Editor dtpad runs only in standalone mode.

A.6 Differences in Invoking Processes

Most processes invoked within the New Desktop are started using actions with associated execution strings (EXEC_STRINGs). With the New Desktop, these EXEC_STRINGs must be a single valid DCL command. Strings that begin with file names are automatically converted to foreign command lines.

A.7 Directory Hierarchies of the New Desktop and CDE

This section describes the differences between the directory hierarchies of the New Desktop and those of CDE.

CDE was developed for UNIX systems. The CDE documentation, which is provided on line with the New Desktop, uses UNIX path specifications.

A.7.1 System Default Configuration Directories

Table A-1 shows the CDE path specifications that correspond to the New Desktop system default configuration directory names. For more information about the CDE file system or directory tree structure, see the dtfilsys.5 reference page, which you can access with the Man Page Viewer.

The Man Page Viewer is located in the Desktop Apps group in Application Manager. To view dtfilsys.5, access the Man Page Viewer and enter dtfilsys.5 at the Man Page prompt.

Table A-1 System Default Configuration Directories
OpenVMS Directory Name UNIX Path Specification
CDE$SYSTEM_DEFAULTS:[000000] /usr/dt
CDE$SYSTEM_DEFAULTS:[APP-DEFAULTS. lang 1] 2 /usr/dt/app-defaults/<lang>
CDE$SYSTEM_DEFAULTS:[APPCONFIG] /usr/dt/appconfig
CDE$SYSTEM_DEFAULTS: -
[APPCONFIG.APPMANAGER. lang 1]
/usr/dt/appconfig/appmanager
CDE$SYSTEM_DEFAULTS:[APPCONFIG.HELP. lang 1] /usr/dt/appconfig/help
CDE$SYSTEM_DEFAULTS:[APPCONFIG.ICONS. lang 1] 3 /usr/dt/appconfig/icons
CDE$SYSTEM_DEFAULTS:[APPCONFIG.TYPES. lang 1] /usr/dt/appconfig/types
CDE$SYSTEM_DEFAULTS:[BACKDROPS] /usr/dt/backdrops 4
CDE$SYSTEM_DEFAULTS:[BIN] /usr/dt/bin
CDE$SYSTEM_DEFAULTS:[CONFIG] /usr/dt/config
CDE$SYSTEM_DEFAULTS:[CONFIG. lang 1] /usr/dt/config/<lang>
--- /usr/dt/dthelp 5
CDE$SYSTEM_DEFAULTS:[EXAMPLES] /usr/dt/examples 4
--- /usr/dt/include 5
DECW$INCLUDE:, DT: /usr/dt/include/Dt 4
SYS$MANAGER:CDE$STARTUP.COM /usr/dt/install/dec/start.cde.dec
CDE$SYSTEM_DEFAULTS:[LIB] /usr/dt/lib
CDE$SYSTEM_DEFAULTS:[MAN] /usr/dt/man 4
CDE$SYSTEM_DEFAULTS:[PALETTES] /usr/dt/palettes 4
--- /usr/dt/share 5

1For the value of lang (or %L) in a directory or file name on OpenVMS, any dot (.) or at sign (@) in the locale name is converted to an underscore (_). For example, fr_FR.ISO8859-1 on UNIX is FR-FR_ISO8859-1 on OpenVMS.
2Application default files on UNIX have no file extension. On OpenVMS there is a .DAT file extension on each application default file in the [APP-DEFAULTS] directory. For example, /usr/dt/app-defaults/C/Dtpad is CDE$SYSTEM_DEFAULTS:[APP-DEFAULTS.C]DTPAD.DAT in the New Desktop. (This does not apply to resource files located in the configuration directory hierarchy.)
3Icon pixmap and bitmap files that contain multiple dots in their file names have been converted to an OpenVMS file name syntax. The second dot in the file name becomes an underscore in the New Desktop. For example, sysinfo.l.pm becomes SYSINFO.L_PM.
4On a UNIX system, the file path specifications for the backdrops, examples, include, man, and palettes directories are links to a share directory. On an OpenVMS Alpha system, the directories for these same files contain the actual files.
5There is no corresponding directory in the New Desktop.


Previous Next Contents Index