Chapter 15. Common Desktop Environment

CONTENTS

•  Why a Graphical User Interface (GUI)?
•  CDE Basics
•  Customizing CDE
•  CDE - Advanced Topics
•  X, Motif, and CDE Configuration Files
•  The Sequence of Events When CDE Starts
•  CDE and Performance
•  Conclusion

The Common Desktop Environment (CDE) represents the effort of major UNIX vendors to unify UNIX at the desktop level. CDE is widely used by X terminal and workstation users on many UNIX systems. Because you may be managing many UNIX variants that run CDE, I'll cover CDE on IBM's AIX systems, Hewlett-Packard's HP-UX systems, and Sun Microsystems' Solaris systems. This chapter provides an introduction to CDE: it touches on the basics of CDE's look and feel, describes making changes to the CDE environment, and offers a bit of background about the X, Motif, and CDE relationships. CDE versions used to write this chapter are: AIX CDE 1.0, HP-UX CDE 2.1.0, and Solaris CDE 1.3. Newer releases will have enhanced features, but, in general, they should still work the same.

Several features make it easy to customize CDE. The Style Manager, which every user has access to, makes it easy to customize CDE on an individual user basis. Sooner or later, however, you may want to provide some common denominator of CDE functionality for your users. If, for instance, you have an application that most users will run, you can set up environment variables, prepare pull-down menus, provide suitable fonts, etc., that will make your users more productive. Users can then perform additional customizations such as defining File Manager characteristics and selecting backgrounds.

To help you thoroughly understand CDE, I'll cover the following topics:

1. Why a Graphical User Interface (GUI)?

2. CDE Basics

3. Customizing CDE

4. CDE - Advanced Topics

   • The Relationships among X, Motif, and CDE

   • X, Motif, and CDE Configuration Files

   • The Sequence of Events When CDE Starts

   • CDE and Performance

First, I'll provide you with the reasoning behind providing a graphical interface rather than the more common, but also more cumbersome, line-by-line terminal interface. An overview of the CDE desktop workspaces follows. This is divided into two sections: AIX and HP-UX (because they are so similar) and Solaris. Each will give an overview of the front panel features. Next I'll guide you through making some CDE customizations. These customizations will give you a working basis for making more advanced changes on your own. I'll show you how to make some basic, simple changes, and then more complex changes, ending with modifying the login screen with a new logo and new welcome messages. Last, I'll delve into the more advanced topics of X, Motif, and CDE relationships, configuration file usage and location, what happens internally when CDE starts up, and some CDE performance tips.

Why a Graphical User Interface (GUI)?

For computers to be used on every desktop, they had to be made easier to use. A new method of accessing computer power was required, one that avoided the command-line prompt, didn't require users to memorize complex commands, and didn't require a working knowledge of technological infrastructures such as networking. Not that this information was unimportant - far from it. The information was both too important and too specialized to be of use to the average worker-bee computer user. A knowledge of their applications was all that was important for these users. After all, so the reasoning goes, to drive a car, one doesn't have to be a mechanic, so why should a computer user have to understand computer technology? The graphical user interface (GUI) makes computers accessible to the application enduser.

Figure 15-1 illustrates the relationships among the computer hardware, the operating system, and the graphical user interface. The computer is the hardware platform on the bottom. The operating system, the next layer up, represents a character-based user interface. To control the computer at this level, users must type commands at the keyboard. The next several layers, beginning with the X Window System, represent the graphical user interface. To control the computer at these levels, users manipulate graphical controls with a mouse.

Figure 15-1. User Interface Components

GUIs replaced memorization with exploration. A user could now use pull-down menus, push buttons, sliding scroll bars, and other direct manipulation to use a computer. Typing operating system commands to perform a function is greatly reduced. With a GUI, a computer is both easier to learn and easier to use.

While fairly inexpensive in terms of dollars (CDE is bundled "free" with the operating system), GUIs are not without cost in terms of RAM usage and performance. Despite this performance expense, GUIs have become a permanent part of the computing environment. The benefits of their utility are worth the cost.

Beyond the graphical controls that reduce training, make mundane tasks simpler to do, and generally ease the stress of using a computer, two other benefits of GUIs are worth mentioning: multiple windows per display and client-server topology.

The benefit of multiple windows that GUIs provide is that each window (literally a rectangular area surrounded by a window frame) contains a separate application. The user can work with multiple windows open. CDE goes one step further: its multiple workspaces allow users to separate application windows by task into specific workspaces. For instance, in a workspace named "Mail," users may have application windows showing the list of incoming electronic mail, a mail message they are currently reading, and a message they are composing for later transmission. In another workspace called "Financials," they could be working on several spreadsheets, each in its own window.

Client-server topology enables the computing resources spread around a network to be accessed efficiently to meet computing needs. In a client-server topology, powerful computers on the network are dedicated to a specific purpose (file management on a file server and running applications on an application server). Users working on less powerful client computers elsewhere on the network access the files or applications remotely. A file server reduces system administration by centralizing file backup, enabling the system administrator to back up only the file server, not each individual client computer. This setup also ensures that files will be backed up at regular intervals. An application server reduces operating costs by reducing the number and size of storage disks required and the size of RAM required on each client computer. A single version of an application resides and runs on the application server and is accessed by multiple users throughout the network.

Although this topology sounds complicated, the CDE GUI makes it easy. To access a file, users "drag and drop" a file icon from the file manager window. To start an application, users double-click the application icon. To print a file, users drag the file to the icon of the appropriate printer in the front panel and drop it there. Users don't have to know where these files and applications are, what directories they are in, what computers they are on, or how they are accessed. The underlying infrastructure and control you have put in place, along with the power of the GUI, allow users to concentrate on their work and not on the mechanics of their computer.

CDE Basics

Because most systems come with a set of CDE user guides, I'm going to give only an overview of what CDE looks like and the main areas we will be working with when we do some customizations. Along the way, I'll point out similarities and differences among the different flavors of CDE.

The CDE login screen presents you with several choices before you even log in. Under the area where you enter your user name are four buttons: OK, Start Over, Options, and Help. OK is just the same as pressing Enter when you enter your login and then your password. The Start Over button clears your user login and allows you to start over. Options provides you with some initial session configuration that would need to be made before you log in. Language allows you to change your default language. Suppose that you need to test your company's software in another language. Assuming that the proper language is preloaded on your system, you can swap between the languages for testing by simply choosing CDE to come up in a different language. Session allows you to choose to come up in the CDE desktop session or into a Failsafe session, which is an X session but without the CDE desktop. Solaris also has options to log in to their OpenWindow Desktop or into the User's Last Desktop. Command Line Login allows you to log in without CDE being invoked. This would be just a regular terminal mode session. Reset Login Screen does just what its name suggests. And finally, Help lists all these features with a brief description of each.

The login screen itself displays a CDE logo, an operating system logo such as AIX, or possibly your company's logo. A welcome message appears along with a place to enter your user login. After entering your user name, you are prompted for your password. Once entered and verified as correct, CDE is started and the desktop is displayed. On Solaris systems, the first time you log in, you are presented with a choice as to whether you want to log into CDE or OpenWindows Desktop.

The CDE desktop is comprised of four desktop workspaces and a front panel shared by each. The front panel is an easy-to-use interface to various applications, commands, and tools. The various components are easily accessed by the simple point-and-click method. Front panel components are a collection of objects, subpanels, and access to desktop workspaces. Some objects are used only to display items such as the clock, whereas others, when clicked, either bring up an application, such as the calendar or dtmail, or perform an action, such as the lock or the exit action icons. Subpanels pop up a menu of objects that can be accessed. These objects can also simply display items or bring up applications. By default, on AIX and HP-UX, you see Personal Printer subpanels, Personal Applications subpanels, and Help subpanels. On Solaris, all panels contain subpanels. Subpanels can be added to the other panels on AIX and HP-UX, as you will see in the next section "Customizing CDE." You can tell that these have subpanels, because they each have a little arrow above the panel where you click to pop it up. In the center of the front panel are four workspaces. These provide areas in which to perform related tasks, enabling the user to separate work and not clutter up the desktop.

CDE on AIX and HP-UX is very similar and, in general, what is displayed on the front panel on one is the same as on the other. Solaris, however, while retaining the basic CDE look and feel, has greatly expanded what is included on the default front panel and the subpanels behind it. I'm going to give an overview of CDE as found on HP-UX and AIX first. Then I'll point out the Solaris enhancements to CDE.

CDE on AIX and HP-UX

The front panel is divided into 11 main areas: five panels, one workspaces area, and five more panels. I'll give an overview of each area from left to right, beginning with the Clock and ending with the Trash Can, as shown in Figure 15-2.

Figure 15-2. Front Panel

Clock - As you would expect, this displays the current time.

Calendar - The Calendar icon displays the current date, and, when clicked, brings up an appointment calendar. The calendar allows you to set appointments and reminders and to create a task list. Appointments can be set as a one-time-only events or as recurring. You can be notified of an appointment by a beep, a pop-up message, or an e-mail. The calendar and associated appointments can be displayed by the day, the week, or the month. A yearly calendar can also be displayed, but without appointments.

File Manager - The File Manager opens a window that displays your home directory and associated files. From here, you can do any number of basic file manipulations, such as copy a file, move a file, delete a file, or execute a program or script. More infrequently used operations, such as creating a symbolic link or changing file permissions or ownership, can also be done here. Removing a file from within File Manager moves it to the Trash Can rather than permanently deleting the file. This way, if you decide that you need it back, you can simply retrieve it from the Trash Can rather than having it restored from a backup - a more time-consuming operating. However, note that the Trash Can is automatically "emptied" at the end of every session. So when you log off, the files are permanently removed.

Personal Application - The Personal Application subpanel contains the CDE's text editor, dtpad, and terminal emulator, dtterm. It also contains the Icon Editor. The dtpad is an easy-to-use, full-screen text editor. As in a PC-based word processor, dtpad allows you to move the cursor anywhere to add, change, and delete text, unlike the popular vi, which is a line-by-line text editor. CDE's dtterm is a good basic terminal emulator. The Icon Editor opens bitmap (.bm) or pixmap (.pm) files and allows you to edit them.

The Personal Applications subpanel is the first place, we find the Install Icon application. This is where new icons are added to the subpanel. This allows the application associated with the icon to be executed when the icon is double clicked. We'll be using this when we modify the desktop in "Customizing CDE."

Mail - The CDE mailer, dtmail, is invoked when this icon is clicked. From here, mail messages can be composed, messages replied to, and messages forwarded. Most advanced mail features that you've come to think of as basic features are included: items such as adding attachments to messages, replying to just the sender or all recipients, and setting automatic messages saying that you're on vacation. Another feature is when a new message arrives, the dtmail icon changes to show a letter popping into the mailbox.

Workspace Area - The next four items comprise the workspace area.

Lock Button - The Lock button allows you to lock your session while you're away from your desk. This security feature keeps others from viewing or accessing your work when you're not there. It saves you from logging off and on every time you need to step away. Your login password, or root's password, must be entered to unlock it again.

Workspace Switch - Four in number, these are the separate workspaces created by default. These allow you to organize your work so that your workspace doesn't get cluttered up. By using the workspaces, you can keep work on different tasks, applications, or systems separated from each other. You change from one workspace to another simply by clicking on the workspace number: One, Two, Three, or Four. You'll notice that no matter what workspace you are in, the Front Panel follows you. In "Customizing CDE," you'll see how easily you can increase the number of workspaces and change the names.

Activity Light - The Activity light, quite simply, blinks when the system is busy doing work.

Exit button - The Exit button is where you log out of CDE, terminating your CDE session. Upon exiting, depending on how you have CDE configured, you are prompted to resume your current session or return to your home session. If you choose to resume your current session, the next time you login, the desktop looks exactly the same as it does when you log out - as closely as possible. Some things, such as remote logins, are not possible, but others are, such as having an application automatically executed. If you choose to return to your home session, the next time you log in, you are returned to a known, preset configuration. This configuration is set in the Style Manager panel, discussed shortly.

Personal Printers - This subpanel contains printers that you have configured on your system, including the default printer designated as such and the Print Manager. The front panel icon is that of the default printer. To print one of your documents, simply drag it from the File Manager and drop it on the printer icon. The Print Manager allows you to view queued print files and remove them before they print. However, this works only with printers directly managed by your system. In today's networked offices, printers are usually shared and the print manager function is on a server, probably in the next building.

Style Manager - The Style Manager is one of those places where you can either get really creative getting your desktop to look just like you want or waste a lot of time - depending on your point of view. Here is where you personalize your login to the system to your own preferences. You can change your font size, your background, your mouse speed, and whether or not your session automatically locks after a certain amount of non-activity, or idle time. This is where you can set your home session, as referred to earlier, to come back to every time you log in or set your system to return to the current session or choose the option of being asked every time you log out. One other configuration you can make here is whether your window focus follows your mouse or whether you have to click on a window before it is the active window. On AIX systems, you can toggle on or off whether the workspaces are displayed on the front panel.

Application Manager - When opened, the Application Manager displays folders with useful applications and actions. Although they differ among manufacturers and even operating systems for that matter, AIX, HP-UX, and Solaris all have some basic features: Desktop Applications, Desktop Tools, Information, and System Administration. Desktop Applications contains such applications and tools as Calculator, Man Page Viewer, Icon Editor, and Create Action. Desktop Tools includes tools like xterm, xwd capture, compress files, and reload resources. System Administration contains operating system-specific applications such as SAM in HP-UX, SMIT in AIX, and Admintool in Solaris, besides more generic actions such as change password. Take the time to look around here. You'll find many items you may want to incorporate on your customized CDE front panel. I, for one, have found the Man Page Viewer to be an invaluable resource and have moved it to my front panel, where it can be readily accessed.

Help - The Help subpanel is a compilation of the Help Manager, a Desktop Introduction, Front Panel help, and an On-Item Front Panel help mechanism. The Help Manager is the main online help facility for CDE. This is a comprehensive help system with topic trees and the ability to search the index using keywords or pattern matching, backtrack where you've been in the help manager, and view the history of items for which you requested help. The Desktop Introduction is an overview of CDE and how it works. The Front Panel help facility gives information about how to use the front panel icons, subpanels, and workspaces. The On-Item Front Panel help mechanism allows you to click on the front panel item about which you wish assistance. Along with the Help Subpanel, Help can also be requested by pressing the F1 function key. If installed on your system, AIX may also include Basic Desktop Customization Help and Base Library.

Trash Can - The Trash Can, used with the File Manager, holds files and folders that you have deleted during the current session. Using the facility allows you to quickly retrieve files that you should not have removed. The Trash Can can be "emptied" at any time to permanently remove items. Also, the Trash Can is "emptied" when you log out of your session.

CDE on Solaris

As mentioned earlier, Solaris has embellished CDE, adding many more subpanels and items to the subpanels, as shown in Figure 15-3. Where Solaris has greatly changed the panel and subpanels, I'll give an overview of what you'll find, as I did in the previous section on AIX and HP-UX. Where they are the same, I'll simply note that they are the same.

Figure 15-3. Front Panel

Like AIX and HP-UX, Solaris' front panel is divided into 11 main areas: five panels, one workspaces area, and five more panels. I'll give an overview of each area from left to right, beginning with the World and ending with the Trash Can.

Links - As you might guess by the World icon, this is where you access the world. Solaris' Web browser, HotJava, lives here. There are also actions included to access Personal Bookmarks for the Web browser, and a Find Web Page search engine. As indicated on the front panel icon, the World icon has a clock on it, too.

Cards - The calendar is the same as on AIX and HP-UX. However, included in the subpanel is Find Card, which is a rolodex-type address manager.

Files - Although the title is slightly different, this is where the File Manager resides. In the subpanel are special icons to perform file actions associated with: Properties, Encryption, Compress File, Archive, and Find File. Solaris has also included actions to manage your floppy disk drive and CD-ROM.

Applications - Renamed simply Applications, here is where you'll not only find the Text Editor, but also Text Note and Voice Note. For the audio enabled, Voice Note allows you to play, record, or save audio files with WAV, AU, and AIFF formats. On this subpanel, you'll also find the Applications subpanel found under Application Manager on the AIX and HP-UX systems. As on the others, this includes Desktop Applications, Desktop Tools, Information, and System Administration. These are basically the same on all systems.

Mail - This subpanel, in addition to dtmail, has been enhanced to include a Suggestion Box. A very clever idea, this automatically opens up a message, pre-addressed to Sun Microsystems, Inc., so that you can send them your suggestions.

Workspace Area - The next five items comprise the workspace area:

Lock button - Same as on AIX and HP-UX.

Workspace switch - Same as on AIX and HP-UX.

Progress Indicator - This is the same as the Busy Indicator on AIX and HP-UX.

Exit button - Same as on AIX and HP-UX.

Personal Printers - Same as on AIX and HP-UX.

Tools - The Style Manager is located here and is displayed on the front panel. You'll also find easy access to the CDE error log, and Find Process allows you to view all processes running on your system and kill selected ones. The Customized Workspace Menu and Add Item to Menu actions allow you to easily modify the Workspace Menu. The Workspace Menu is accessed by placing the mouse over a blank area of the desktop and pressing the right mouse key. Whereas AIX and HP-UX come with a generic menu, Solaris has incorporated the front panel and subpanel actions into the Workspace Menu as another way to access these actions.

Hosts - Here, Solaris differs greatly from AIX and HP-UX. The Hosts subpanel contains system-related actions. On the front panel, you'll find the Performance Monitor icons indicating how busy your CPU and disk drives are. From the subpanel, this Host opens up the dtterm terminal emulator, and Console opens up a dtterm specifically for displaying console messages. System Information provides system information including system name, hardware model, network IP address and domain, physical and virtual memory, operating system version, and date and time last rebooted. Find Host is the same as Find Card in the Cards subpanel.

Help - Same as on AIX and HP-UX.

Trash - TheTrashCan is thesame, with theaddition of a sub-panel icon to "empty" the Trash Can.

This concludes the overview of the look and feel of CDE. Armed with this knowledge, you can easily navigate around your desktop environment with confidence and ease. Next, you'll learn how to change that look and feel to conform to your work environment.

Customizing CDE

Before you modify any CDE configuration files, first develop a strategy. I know that I've mentioned this before, but it's important enough to mention again.

The following questions should get you started:

1. What are your users' needs?

2. Which of those needs can be met by reconfiguring CDE?

3. At what level should these changes be made (system-wide, groups of users, individual users only)?

4. Which CDE files do you need to modify (names and locations)?

5. What are the changes and what is their order within the file?

It's also a good idea to have handy a binder containing man pages for each of the CDE components (for looking up resources and their values) and a copy of each of the CDE configuration files.

Now that you have a good understanding as to how CDE works, I'll lead you through making changes and customizing the system for either the entire user community or each individual user.

I'll precede each change with a discussion of what is involved in making the change. I'll be making some basic, simple changes as well as some more advanced changes to show you how versatile CDE can be.

One thing I need to mention is that all these changes can be made on any system. And knowing how to do these tasks "the hard way" increases your understanding of what these tools are doing for you in the background. So be sure to give each one a try.

Making Changes Using Style Manager

Font Size

When we first log in to CDE and the workspace comes up, as shown in Figure 15-4, one of the first things many users change is the size of the font. Initially set to 4, most users want a bigger font. This change is easy.

Figure 15-4. Style Manager

1. Click on the Style Manager icon on the front panel. This action brings up the Style Manager.

2. Click on Font.

3. Highlight 5.

4. Click on OK.

Backdrop and Colors

The Style Manager is also where we can change the backdrop and colors:

1. Click on Backdrop and we are presented with a variety of backdrop choices.

2. After we see one we like, such as Pebbles, we can click on apply and then click on close to change our backdrop. Notice, however, that this action changes the backdrop only for the workspace that we are in.

   To change the other workspaces, we can either go to them and bring up the Style Manager in that workspace or, because we already have Style Manager up, we can click in the top right corner on the little "-" on the window itself, above "File," and access the pull-down menu. From here, we can choose Occupy All Workspaces. Then we can simply go to the other workspaces, and Style Manager is already up and ready for us there. The Backdrop area is the only place we have to worry about moving to other workspaces.

3. To change colors, click on the Color icon. We are given a list of different color schemes from which to choose. And if one isn't quite to our liking, we can easily modify the color, hue, brightness, and contrast. We can even grab a color from somewhere else, such as an image off the Internet, to include in the color scheme. Once we have the colors we like, we can save the scheme with its own name.

Adding Objects to or Removing Objects from the Front Panel

The front panel can make life just a little easier for us by including frequently used items on it. One of the most frequent actions is opening up a terminal window. And although CDE comes with dtterm as the default terminal window, we sometimes might want to use an xterm window. We'll add it to the Personal Applications subpanel, where dtterm lives on AIX and HP-UX systems. Solaris users can do the same by putting the xterm on the Hosts subpanel, where the Host terminal emulator lives.

You have two ways to add objects to the CDE front panel:

• Drag and drop them into a slideup subpanel and then make them the default for that subpanel.

• Modify the /etc/dt/appconfig/types/C/dtwm.fp configuration file. This approach will be used later when we create actions and file types.

The basic actions to add a control button through drag and drop are as follows:

• Drag the application icon you want as a front panel button from an application manager view and drop the icon onto the installation section (the top section) of the appropriate subpanel.

• Place the mouse pointer over the icon and press mouse button 3 to display the subpanel menu.

• Select Copy to Main Panel.

1. Click on the up arrow of the Personal Applications subpanel on AIX or HP-UX or on the Hosts subpanel on Solaris so that it pops up.

2. Click on the Application Manager icon, where Desktop Applications and Desktop Tools live.

3. Double click on Desktop_Tools. Here you'll find Xterm.

4. Drag and drop the Xterm icon from Desktop_Tools to the Install Icon box at the top of the Personal Applications subpanel on HP-UX and AIX, or Hosts on Solaris.

Now if we want to include xterm on the front panel:

1. Right click on theXtermicon in the Personal Applications or Hosts subpanel.

2. Select Copy to Main Panel or Promote to Front Panel, depending on which CDE you are using.

Adding Another Workspace

Another easy change to the front panel is to add another workspace. CDE comes with a default of four workspaces, but this is easy to change. We'll add one more and call it "Web View." This can be the window where we'll access the Internet.

1. Place the mouse in the Workspace area of the front panel and press the right mouse button.

2. Select Add Workspace from the pull-down menu. The workspace "New" has been added.

3. Right click on thenewworkspacelabeled "New" and select Rename. Type Web View and press Return.

If we want to delete a Workspace, simply right-click on the Workspace to be removed and then select delete.

Making these kinds of changes is easy, and they help personalize the workspace for the individual user.

Changing the Front Panel in Other Ways

In addition to adding and removing buttons, you can shape the front panel in other ways. These other ways use Workspace Manager resources to modify default values. The following resources relate to the front panel:

• clientTimeoutInterval - Length of time the Busy light blinks and the pointer remains an hourglass when a client is started from the front panel.

• geometry - x and y coordinate location of the front panel.

• highResFontList - Font to use on a high-resolution display.

• lowResFontList - Font to use on a low-resolution display.

• mediumResFontList - Font to use on a medium-resolution display.

• name - Name of the front panel to use when multiple front panels are in dtwm.fp.

• pushButtonClickTime - Time interval distinguishing two single mouse clicks from a double click (to avoid double launch-ing an application accidently).

• waitingBlinkRate - Blink rate of the front panel Busy light.

• workspaceList - List of workspace names.

• title - Title to appear on a workspace button.

Like all other workspace manager resources, these front-panel resources have the following syntax:

Dtwm*screen*resource: value 

For example, suppose that instead of the default four work-spaces, all that your users need is a front panel with six workspaces named Mail, Reports, Travel, Financials, Projects, and Studio. Fur-ther, they prefer a large font and have decided upon New Century Schoolbook 10-point bold. As system administrator, you'd make everyone happy with the following resource specifications:

Dtwm*0*workspaceList: One Two Three Four Five Six  Dtwm*0*One*title: Mail  Dtwm*0*Two*title: Reports  Dtwm*0*Three*title: Travel  Dtwm*0*Four*title: Financials  Dtwm*0*Five*title: Projects  Dtwm*0*Six*title: Studio  Dtwm*0*highResFontList:               -adobe-new century schoolbook-bold-r-normal\               --10-100-75-75-p-66-iso8859-1 

The screen designation is usually 0, except for displays capable of both image and overlay planes. The order of screens in the X*screens file is what determines the screen number; the first screen, typically the image plane, is designated as 0. Note also the inclusion of workspace names (One, Two, Three, Four, Five, and Six) in the six-title resource specifications.

These changes can be added to the sys.resources file, which is discussed in detail in "Advanced Topics" later in this chapter. These changes can also be made by use of the EditResources action to insert the new resource lines into each user's RESOURCE_MANAGER property and then restart the workspace manager.

The obvious disadvantage is that you have to physically go to each user's work area and take over the machine for a few minutes. However, on the plus side, the changes are immediate and are automatically saved in the correct dt.resources for users who restore their current session. You also avoid having your changes overwritten, which could happen if you modify the right dt.resources file at the wrong time, while the user is still logged in.

Modifying Things in Slide-Up Subpanels

Subpanels are defined in dtwm.fp after the front panel and front-panel control definitions. To associate a subpanel with a front panel control button, the front-panel control name is listed as the container name in the subpanel definition.

Note: /etc/dt is where global changes are made. $HOME/.dt is where local or individual user changes are made.

To add a slid-up subpanel to the front panel, follow these steps:

1. Copy the file /usr/dt/appconfig/types/C/dtwm.fp to either /etc/dt/appconfig/types/C/dtwm.fp or $HOME/.dt/types/ dtwm.fp.

2. Decide which control button with which the slide-up is to be associated.

3. Create the subpanel definition file in dtwm.fp. This will take the following form:

   SUBPANEL   SubPanelName  { CONTAINER_NAME  AssociatedFrontPanelControlButton  TITLE  SubPanelTitle  } 

4. Create subpanel control definitions for the subpanel. These will take the following form:

   CONTROL  ControlName  { TYPE  icon  CONTAINER_NAME   SubPanelName  CONTAINER_TYPE   SUBPANEL  ICON BitmapName  PUSH_ACTION   ActionName  } 

As with front panel control buttons, it's easier to copy and modify an existing subpanel file than to start from scratch.

Changing the Default Printer Name Display

We'll now make an easy change to one of the slide-up subpanels. If we pop up the Personal Printers subpanel, it shows that we have a default printer configured, but not the name of it. Let's go back into the front panel file, dtwm.fp, and change that:

1. Bring up your favorite editor, such as dtpad or vi, andedit /$HOME/.dt/types/dtwm.fp.

2. Scroll down to CONTROL Printer. You'll see that the LABEL is Default. Change or add to that the name of your default printer. My printer is called a464.

   LABEL Default - a464

3. Save the file and restart Workspace Manager. Position the mouse over a blank area on your workspace and press the right mouse button. Select Restart Workspace Manager. On Solaris, press the right mouse button to bring up the Custom-ized Workspace Menu. From here, select Windows, where you'll find the Restart Workspace Manager key.

Pop up the Personal Printers subpanel to see what the default printer really is. Of course, if we change the default, we'll have to change the front panel again. But we know how to do that now, don't we! Figure 15-5 shows the Front Panel.

Figure 15-5. Front Panel with Changes

Front Panel Animation

Animation for front panel or slide-up subpanel drop zones is created by displaying a progressive series of bitmaps. By convention, the bitmaps are in /usr/dt/appconfig/icons. The list of bitmaps to display is contained in animation definitions at the end of dtwm.fp.

To create an animation sequence for a drop zone:

1. Create a progressive series of bitmaps.

2. Add a list of these bitmap files to the appropriate configuration file using the following syntax:

   ANIMATION AnimationName  {  bitmap0   bitmap1   bitmap2   bitmap3   bitmap4   bitmap5  } 

3. Add a line to the appropriate control definition using the syntax:

   DROP_ANIMATION AnimationName 

Adding Items to the Workspace Menu

The workspace menu is defined in the sys.dtwmrc file. As mentioned in the overview of the front panel for Solaris, the Workspace Menu is accessed by placing the mouse over a blank area of the desktop and pressing the right mouse key. Where AIX and HP-UX come with a generic menu, Solaris has incorporated the front panel and subpanel actions into the Workspace Menu as another way to access these actions. However, we can create customized Workspace Menu for all three systems using the left mouse key to access it. We'll be doing this task next.

A cusotomized Workspace menu can contain frequently used commands and applications. The customized menu is usually accessed by pressing the left mouse button, which pops up the menu for viewing and selection. A Workspace menu comes in handy for those who have a set number of things they do regularly. For instance, a programmer who uses C++, vi, and isql may have a menu with those items, or a system administrator may have a menu with df, ps -ef, and netstat on it. Or those on an expansive network may want a menu of system logins.

For one or two changes, you can modify the existing Workspace menu. For major changes, it's probably easier to insert an entirely new menu definition in sys.dtwmrc.

A menu definition has the following syntax:

Menu MenuName  {  "Menu Name"         f.title   "Frame"             f.exec /nfs/system1/usr/frame/bin/maker   "Second Item"       action   "Third Item"        action  } 

The first line specifies the menu name, following the keyword Menu. The lines between the curly braces list the items that appear in the menu in their order of appearance; thus the first line is the title as designated by the function f.title. The second line is an example of a definition that would start FrameMaker from a remote application server in a distributed environment. Numerous other functions exist, approximately 45 in all. For a complete list, see the dtwmrc (4) man page.

For users to display the menu, you need to bind the menu definition to a mouse button and a screen location using the action f.menu MenuName. For example, if your users want to post the menu by pressing mouse button 3 when the pointer is on the workspace background, you would insert the following line in the Mouse Button Bindings Description section at the end of sys.dtwmrc:

<Btn3Down> root f.menu MenuName 

(Actually, it would be easier to modify the line that's already there by exchanging MenuName for DtRootMenu on the second line.)

Now we'll create a simple menu. Our menu is going to include running FrameMaker, running the vi editor, and logging into a remote system.

1. First we need a copy of the /usr/dt/config/C/sys.dtwmrc file to /etc/dt/config/C:

   

   cp /usr/dt/config/C/sys.dtwmrc /etc/dt/config/C/sys.dtwmrc 

If we were going to make this a local change for one user only, it would be copied to /$HOME/.dt and renamed dtwmrc. For the admin1 user, that would be /home/admin1/.dt/dtwmrc or on Solaris in /home/admin1/.dt/C/dtwmrc.

2. Go into our favorite editor and modify the file. We're going to add our new menu just after the DtRootMenu entry, which we see on our system as the left mouse button's "Workspace Menu." Add the following:

   Menu AdminMenu      {       "Admin1's Menu"     f.title       "Frame Maker"       f.exec "/nfs/system1/usr/frame/bin/maker"       "VI Editor"          f.exec "xterm -e /usr/bin/vi"       "Login systemA"   f.exec "xterm -geometry 80x50+830+0 -sl 200 -bg  DarkOrchid4 -fg white -n SYSTEMA -T SYSTEMA -e remsh systemA &"      } 

The f.title function shows that this is the menu title. f.exec means to execute the following string. Notice that FrameMaker does not need a terminal window because it uses its own, whereas vi and the login both need a terminal window in which to run. Also, I embellished on the xterm for the login, making the terminal window very large, with lots of terminal memory and using specific colors.

Now, let's restart the Workspace Manager and try out our new menu:

3. Position the mouse over a blank area on the workspace and press the left mouse button. Select Restart Workspace Manager.

Creating pull-down menus is easy and can easily be expanded by adding submenus to the menu. Just use the function f.menu followed by the menu name. Add the following just after "Admin1's Menu":

"Work Menu" f.menu WorkMenu''  And then after the } from the Menu AdminMenu section, add:  Menu WorkMenu  { .  } 

Performing these advanced functions really isn't so hard. The hardest part is remembering which directories to put the files in: /etc/ dt for global changes or $HOME/.dt for individual changes.

Creating Control Buttons, Actions, and File Types

An action starts a process such as a shell script or an application. An action can be connected to a front-panel button to start when the button is clicked. An action can be connected to a front panel drop zone to be performed when a data file is dropped on the drop zone. An action can be associated with an icon in a file manager window so that the action can be started by double-clicking the icon. An action can be associated with a particular data type so that double-clicking the data file icon starts the action and opens the data file.

In addition to setting up a front panel and default session to meet your users' needs, the single most important thing you can do to make computing life easier for the people who depend on you is to create actions and data types.

CDE actions and data types are defined in files that end in.dt. Similar to most other CDE configuration files, *.dt files have a system-wide version that can be copied into a user's personal directory and customized for personal use. Most system-wide *.dt files are found in /usr/dt/appconfig/types/C; personal *.dt files are created by copying user-prefs.dt from /usr/dt/appconfig/types/C to $HOME/ .dt/types.

The default search path that CDE uses to look for actions and file types includes the following main directories in the order listed:

• $HOME/.dt/types

• /etc/dt/appconfig/types

• /usr/dt/appconfig/types

You can add more directories to the search path using the DTDATABASESEARCHPATH environment variable. Insert this environment variable and the new search path into /etc/dt/config/ Xsession for a system-wide influence. Insert the environment variable and search path into $HOME/.dtprofile for individual users.

Control Buttons - The basic control definition has six parts:

• CONTROL name - The definition name. This is the only part of the definition outside the curly braces.

• TYPE - The type of control. Several types exist. The most useful for customizing the front panel are probably blank and icon. A blank is useful as a space holder. An icon can start an action or application or be a drop zone.

• ICON - The bitmap to display on the front panel. Front-panel bitmaps are located in the /usr/dt/appconfig/icons directory.

• CONTAINER_NAME - The name of the container that holds the control. This must correspond to the name of an actual container listed in dtwm.fp.

• CONTAINER_TYPE - The type of container that holds the control. This can be BOX, SWITCH, or SUBPANEL, but it must agree with the type of the container name.

• PUSH_ACTION - This is what happens when the control button is pushed. PUSH_ACTION is just one of several possible actions. For more information, see the dtwm man page.

To remove a control button from the front panel, type a pound sign (#) in the left-most column of the CONTROL definition line. The (#) turns the control specification into a comment line.

Add a control button by editing the dtwm.fp file:

1. Copy dtwm.fp from /usr/dt/appconfig/types/C to /etc/dt/ appconfig/types/C.

2. Add the new control definition using the following format:

   CONTROL NewControl  { TYPE            icon  CONTAINER_NAME  Top  CONTAINER_TYPE  BOX  ICON            NewControlBitmap  PUSH_ACTION     NewControlExecutable  } 

Action and File Types have their own peculiarities in that each has a couple of parts, and each must live in its own directory location. These peculiarities will be come clear as we create an action on the subpanel. The following are the recommended locations in which to create an action or file type definition:

• Create a completely new file in the /etc/dt/appconfig/types directory. This file has a system-wide influence. Remember, the file must end with the.dt extension.

• Copy user-prefs.dt from /usr/dt/appconfig/types to the /etc/ dt/appconfig/types directory and insert the definition there for system-wide use.

• Copy user-prefs.vf to $HOME/.dt/types and insert the definition there for individual users.

A typical action has the following syntax:

ACTION ActionName  { TYPE type   keyword    value   keyword    value  } 

For example, here's a FrameMaker action:

ACTION     FRAME  {   TYPE     COMMAND    WINDOW-TYPE NO-STDIO  EXEC-STRING /nfs/hpcvxmk6/usr/frame/bin/maker  } 

A typical data type has the following syntax:

DATA_ATTRIBUTES        AttributesName  {   keyword       value    keyword       value    ACTIONS       action, action  }  DATA_CRITERIA  {  DATA_ATTRIBUTES AttributesName   keyword        value   keyword        value  } 

Note that all definitions have the following general syntax:

KEYWORD value 

Notice that a data type definition is actually in two parts: an attribute part and a criteria part. The attribute portion of the data type definition specifies the look of the data type; the criteria portion specifies the behavior of the data type.

For example, here's a file type for FrameMaker files that uses the FRAME action:

DATA_ATTRIBUTES   FRAME_Docs  {  DESCRIPTION    This file type is for FrameMaker documents.   ICON           makerIcon   ACTIONS        FRAME  }  DATA_CRITERIA  { DATA_ATTRIBUTES_NAME   FRAME_Docs  NAME_PATTERN  *.fm  MODE   f  } 

You can create actions and file types from scratch using these formats. However, the easiest way to create an action is to use the CreateAction tool. CreateAction is located in the Desktop Applications folder of the Applications Manager and presents you with a fill-in-the-blank dialog box that guides you through creating an action.dt file containing the action definition. You can then move this file to the appropriate directory for the range of influence you want the action to have: /etc/dt/appconfig/types for a system-wide influence; $HOME/ .dt/types for individual users.

Creating a New Icon and Action

Creating an icon is a challenging task. We could use the Icon Editor found in Desktop_Apps to create a new icon, or we could find a picturewelikeand useit. Onething to be carefulofwhenpulling in a picture, in order for it to be seen correctly on the front panel, is that it has to be no larger than 32x32 pixels or only a portion of the icon will be displayed. Viewing the picture in the Icon Editor shows you the size of the picture. You may want to search through the application directories for useful icons or pull one down from the Internet.

For this entire example, I'm going to use the Instant Information software that comes with HP-UX. This is the manual set on the CD. Other application software will work just as well; just make sure that your paths correspond with the software you are using. Also, I'm going to use a fictitious user's home directory: /home/admin1.

1. Bring up the Icon Editor from the Desktop_Apps (HP-UX), Desktoptools (AIX), or from the Desktop_Tools, on Solaris all in the Application Manager.

2. Choose File -> Open.

3. Enter a path or folder name: /opt/dynatext/data/bitmaps.

4. Enter the file name: logoicon.bm

5. Choose Open.

We'll see the icon and check that it is indeed 32x32. Now we need to save the icon to our own.dt directory.

6. Choose File -> Save As.

7. Enter path or folder name: /$HOME/.dt/icons. For the admin1 user, that would be in /home/admin1/.dt/icons.

If we were going to do this task globally, we'd put this in /etc/ dt/appconfig/types/C.

8. Leave the file name as is.

9. Save.

Now that we have the icon, we need to create an action file and a description file to go with it.

1. Using your favorite Text Editor, enter the following:

   ACTION instinfo  {  LABEL        instinfo  TYPE         COMMAND  WINDOW_TYPE   NO_STDIO  EXEC_STRING   /opt/dynatext/bin/dynatext  DESCRIPTION   This action starts Instant Information  } 

   The LABEL is the name of the action, the TYPE is a command, the WINDOW_TYPE is none (no standard I/O or NO_STDIO) because the application has its own window, EXEC_STRING is the command to be executed, and the DESCRIPTION is just a description of what this action does. Make sure that the NO_STDIO has an underscore and not a dash, and don't forget the last }. I've done both of these and then had fun trying to figure out why the action either didn't appear to exist or, if it did appear, why it wouldn't work.

2. Save this file as /$HOME/.dt/types/instinfo.dt. For the admin1 user, that would be /home/admin1/.dt/types/ instinfo.dt. If this were a global configuration, we'd save the file as /etc/dt/appconfig/types/C/instinfo.dt.

   Now that we have an action, we need to create a description file. Note that this is a new file with just these two lines in it. The contents of this file are irrelevant, but the permissions must include executable.

3. Again, using your favorite editor, enter:

   ACTION instinfo  DESCRIPTION This action starts Instant Information 

4. Save this file as /$HOME/.dt/appmanager/instinfo. For the admin1 user, that would be /home/admin1/.dt/appmanager/ instinfo. If this were a global configuration, we'd save the file as /etc/dt/appconfig/appmanager/instinfo.

5. Change the permissions to include execute as follows:

   chmod 555 /$HOME/.dt/appmanager/instinfo 

Now it's time to modify the front panel to include the icon and action we just created. The front panel file, dtwm.fp, is located in the /usr/dt/appconfig/types/C directory. Because we don't want to overwrite the system file, we need to copy it locally and then modify it for our use.

1. Copy this to /$HOME/.dt/types/dtwm.fp for AIX and HP-UX and to /$HOME/.dt/types/fp-dynamic/dtwm.fp for Solaris. For the admin1 user, that would be:

cp /usr/dt/appconfig/types/C/dtwm.fp /home/admin1/.dt/types/dtwm.fp 

or on Solaris:

cp /usr/dt/appconfig/types/C/dtwm.fp /home/admin1/.dt/types/fp-dynamic/dtwm.fp 

2. Using your favorite editor, modify the local dtwm.fp file.

As we look at the file, we notice that it is in the same order as the front panel is displayed. The clock is the first CONTROL in the file and the first item on the front panel. Also notice that the POSITION_HINTS is 1. Date is next and so is POSITION_HINTS 2. What we want to do is put our new icon and action after POSITION_HINTS 4, the TextEditor CONTROL.

3. Go down just past the } ending CONTROL TextEditor and before CONTROL Mail. At this point, insert the following exactly as shown below. Make sure that the uppercase letters are capitalized and the lowercase letters aren't.

CONTROL Info  {   TYPE             icon   CONTAINER_NAME   Top   CONTAINER_TYPE   BOX   POSITION_HINTS   5   ICON             logoicon.bm   LABEL            Instant Info   PUSH_ACTION      instinfo  } 

4. Now be careful; this part is tricky. The next items have to have their POSITION_HINTS renumbered. But we are going to renumber only the next eight items, beginning with Mail and ending with Trash. Instead of 5 through 12, these are going to become 6 through 13.

5. Save the file.

Now, let's restart the Workspace Manager. If we did everything right, we'll have a new icon, which, when clicked, will bring up Instant Information shown in Figure 15-6.

Figure 15-6. Workspace Menu and New Subpanel and Action

6. Position the mouse over a blank area on the workspace and press the right mouse button. Select Restart Workspace Manager.

A couple of things to remember when creating actions: first and foremost, make sure the PUSH_ACTION and the file names are the same. That similarity is how they find each other. Make sure the that action file ends with.dt and make sure that the description file is executable. If any of these are wrong, the action either won't work or won't appear.

To avoid a lot of typing, sometimes the easiest approach is just to copy an existing definition and insert it where you want your new control to be and then modify it. As you move down the list of control definitions, you're moving from left to right across the front panel (notice that the POSITION_HINTS value increases in each definition). So if you want your new control to be to the right of the date on the front panel, you insert the control on the line below "date" and add a POSITION_HINTS 3 line to your definition; if you wanted your new control to be to the left of "date," insert the control on the line above "date" with a POSITION_HINTS of 1.

The new control definition can be located anywhere in the list of control definitions. The POSITION_HINTS line keeps it from getting inadvertently bumped to a new position. It's still a good idea to copy an existing definition and avoid extra typing; it reduces the chance of typing mistakes. And don't forget to include the curly braces.

Using Different Fonts

Although CDE fonts have been carefully selected for readability, you may have valid reasons to prefer other fonts. To make your fonts available system-wide throughout the CDE environment, put them in /etc/dt/app-defaults/Dtstyle so that they will appear in the style manager's font dialog box. To make fonts available only for a particular X client application, specify the font in the app-defaults file for the application. Just remember, this overrides the fonts in the style manager.

The font dialog box can contain a maximum of seven font sizes. You can adjust this number downward by resetting the value of Dtstyle*NumFonts in /etc/dt/app-defaults/Dtstyle; however, you can't increase the number higher than seven.

The Font Dialog section of the Dtstyle configuration file has seven SystemFont resources and seven UserFont resources. Again, you can have fewer than seven system and seven user fonts, but you can't have more.

To specify fonts for a particular application, use the *FontList resource in the app-defaults file for the application.

To modify font resources on an individual user basis, you can use the EditResources action as described in the earlier section "Changing the Front Panel in Other Ways."

Changing the Login Messages

One of the nice things about CDE is the ability to modify so many parts. You can customize individual login accounts or the entire system. By customizing the login screen, you can show those about to log in the name of the system they are accessing, the company logo, and a personalized greeting. These modifications take place in the Xresources file:

1. As we've done already with the dtwm.fp and dtwmrc files, we will need to copy the system file from /usr/dt/config/C to /etc/dt/config/C as follows:

cp /usr/dt/config/C/Xresources /etc/dt/config/C/Xresources 

2. Go into your favorite editor and bring up the Xresources file so that it can be edited.

3. Go to the GREETING area. Here we'll find the following lines:

!!Dtlogin*greeting.labelString:	Welcome to %LocalHost%
!!Dtlogin*greetingpersLabelString:	Welcome %s

The first line is the message on the initial login screen. Let's change that so that it welcomes us to our company, ABC, Inc.:

1. Remove the comment notations. Unlike shell scripts that most of us are used to, the Xresources file uses two exclamation points as comment notation. Remove the !!.

2. Next, modify "Welcome to %LocalHost%". The %LocalHost% variable is replaced with our system name in the login screen. The line should look like this:

   Dtlogin*greeting.labelString: ABC, Inc, Welcomes You to %LocalHost%

3. Next, let's change the second line to include the department that this system is dedicated to: finance. This second line shows what is displayed when we are prompted for our password. The %s variable is our user name. The line should now look like this:

   Dtlogin*greetingpersLabelString: The Finance Department Welcomes %s

4. Save the file.

5. Now log out and back in. We should see the changes in the login screen. We didn't need to "reload" the file, because the act of logging out and back in does that action.

Changing the Login Picture

Adding a new picture to the login screen is easy if you know one thing. The file has to be a bitmap (.bm) or pixmap (.pm) file. A bitmap file is black and white, and the pixmap file is color. I've tried using other kinds of pictures (.gif and .jpg formats), but they just don't display. The good news is that these can be imported from other systems or the Internet for our use. To make things simple, we're going to use one already on the system. A bitmap showing a birthday cake was found in /usr/lib/X11/bitmaps on an HP-UX workstation. However, I have also successfully pulled down pictures of flowers, the Grand Canyon, and country music singers (note: Donna wrote this chapter not Marty) from the Internet and put them on my system login screen.

1. Once more, let's go into our favorite editor and modify /etc/dt/ config/C/Xresources.

2. Go to the MISC area. Here we'll find the following lines:

   !!Dtlogin*logo*bitmapFile: < bitmap or pixmap file >

3. Delete the leading !!, which are the comment designators.

4. Replace <bitmap or pixmap file> with the name of the bitmap file using the entire path location. The line should look as follows:

   Dtlogin*logo*bitmapFile: /usr/lib/X11/bitmap/cake.bm

5. Save the file.

6. Now log out and back in. We should see the birthday cake in the login screen. Again, we didn't need to "reload" the file, because the act of logging out and back in does that task.

Now that we've seen how easily we can make some simple customizations in CDE for our end users, we should be able to take this knowledge and really make their CDE environments a productive and friendly place to work.

CDE - Advanced Topics

The Relationship among X, Motif, and CDE

X, OSF/Motif, and CDE are enabling framework technologies. Taken together, X, Motif, and CDE make up the three graphical layers on top of the operating system and hardware platform.

The GUI layers provide increasingly richer ease-of-use functions in a progressive series of layers that buffer the end user from the "user-hostile," character-based interface of the operating system layer.

The X Window System

The X Window System consists of the following:

• Xlib - Low-level library for programming window manipulation; graphics capabilities such as line drawing and text placement; controlling display output, mouse, and keyboard input; and application network transparency.

• Xt Intrinsics - Higher-level library for programming widgets and gadgets (graphical controls components such as menus, scrollbars, and push buttons).

• Display servers - Hardware-specific programs, one per display, that manage the graphical input and output.

• Interclient communication conventions (ICCC) - A manual specifying standards for how X client programs should communicate with each other.

• Configuration files - One configuration file that specifies the default session to start (sys.x11start) and another specifying values for resources used to shape the X environment (sys.Xdefaults).

Through these mechanisms, X provides the standard upon which the graphical part of the network-oriented, client/server, distributed computing paradigm is based. A knowledge of Xlib and the Xt Intrinsics is important for programming in X and for programming at the Motif level. For system administrators, however, as long as the display servers work and X client applications are ICCC-compliant, tjeu shouldn't need to delve into the X layer. CDE enables them to view X pretty much as part of "all that underlying technological infrastructure stuff" and focus on developing appropriate configurations of CDE to meet their users' work contexts.

Motif

Motif consists of the following:

• mwm window manager - Executable program that provides Motif-based window frames, window management, and a workspace menu in the X environment.

• Motif widget toolkit - Higher-level library of widgets and gadgets, the graphical components used to control the user environment.

• Motif style guide - A manual defining the Motif appearance and behavior for programmers.

• Configuration files - The system.mwmrc file containing configuration information for the workspace menu and key and button bindings. Resources for the window manager are in mwm in the /usr/lib/X11/app-defaults directory.

Motif provides the window manager for the end user, the widget toolkit for application developers, and the style guide to help developers design and build proper Motif-conformant applications. As with X, system administrators can view Motif mostly as "programmer's stuff," part of the underlying infrastructure, and focus on developing appropriate CDE configuration files.

CDE

As we have already seen, CDE consists of the following:

• Workspace Manager - Executable program that provides Motif-based window frames, window management, a workspace menu, and the front panel.

• File Manager - Program that iconically manages files and directories through direct manipulation.

• Style Manager - Container of dialog boxes that control elements of the CDE environment, such as workspace color and fonts.

• Help Manager - This program provides context-sensitive help text on CDE components.

• Login Manager - Daemon-like application that handles login and password verification.

• Session Manager - Manager that handles saving and restoring user sessions.

• Application Manager - Manager that registers and keeps track of applications in the CDE environment.

• Configuration Files - A big bunch, most of which you can avoid dealing with (see the next section).

CDE also provides a number of basic, end-user productivity-enhancing applications. In general, CDE provides a graphical environment into which users or their system administrator can incorporate the software tools needed to do their work.

X, Motif, and CDE Configuration Files

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, andCDE, theword "resource" hasa 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, the 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 have 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 occur.

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 15-1.

Table 15-1. CDE Configuration Files

* .Xauthority	* sys.font	* Xresources
* .Xdefaults	* sys.resources	* Xservers
* .dtprofile	* sys.sessions	* Xsession
* dtwm.fp	* Xaccess	* Xsetup
* dt.wmrc	* Xconfig	* Xstartup
* sys.dtprofile	* Xfailsafe
*sys.dtwmrc	*Xreset

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 data types 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 15-2 organizes CDE configuration files according to their content and the breadth of their influence:

Table 15-2. CDE Configuration File Influence

Nature of Configuration File	System-Wide Influence	User's Personal Influence
Environment Variables	sys.dtprofile Xconfig Xsession	.dtprofile
Appearance & Behavior Resources	sys.resources Xconfig Xresources sys.fonts	.Xdefaults
File Types & Action Definitions	misc *.dt files	user-prefs.dt
Client Startup at Login	sys.sessions Xstartup Xsession Xreset Xfailsafe	.xsession sessionetc
Workspace Manager & Front Panel	sys.dtwmrc dtwm.fp	dtwmrc user-prefs.fp
Clients/Servers & Access	Xaccess Xservers	.Xauthority

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

Workspace Menu	A menu that displays when mouse button 3 is pressed while the mouse pointer is over the workspace backdrop.
Button Bindings	Definitions of what action happens when a particular mouse button is pressed or released while the mouse pointer is over a particular area (frame, icon, window, or root).
Key Bindings	Definitions of what action happens when a particular key or key sequence is pressed while the mouse pointer is over a particular area (frame, icon, window, or root).

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

Front Panel	The box, usually at the bottom of the workspace, that contains commonly referenced indicators and frequently used graphical controls, including a six-button workspace switch.
Slideup Subpanels	Menus that slide up from the front panel at various locations to provide more functionality without consuming more screen space.

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, such as 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 clients 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:

DISPLAY	The name of the local display
EDITOR	The default text editor
HOME	The user's home directory as specified in /etc/passwd
KBD_LANG	The current language of the keyboard
LANG	The current NLS language
LC_ALL	The value of LANG
LC_MESSAGES	The value of LANG
LOGNAME	The user's login name as specified in /etc/passwd
MAIL	The default file for mail (usually /var/mail/$USER)
PATH	The default directories to search for files and applications
USER	The user name
SHELL	The default shell as specified in /etc/passwd
TERM	The default terminal emulation
TZ	The time zone in effect

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:

EDITOR	The default text editor.
KBD_LANG	The language of the keyboard (usually set to the value of $LANG).
TERM	The default terminal emulation.
MAIL	The default file for mail, which is usually /var/mail/$USER.
DTHELPSEARCHPATH	The locations to search for CDE help files.
DTAPPSEARCHPATH	The locations to search for applications registered with the CDE application manager.
DTDATABASESEARCHPATH	The locations to search for additional action and datatype definitions.
XMICONSEARCHPATH	The locations to search for additional icons.
XMICONBMSEARCHPATH	Same as above.

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 them 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 primaryuse of theXservers 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? Whena 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:

DISPLAY	The name of the local display.
USER	The login name of the user.
HOME	The user's home directory.
PATH	The value of the systemPath resource in Xconfig.
SHELL	The value of the systemShell resource in Xconfig.
XAUTHORITY	The file to access for authority permissions.
TZ	The local time zone.

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 such as 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 such as 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/app-defaults/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 15-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 15-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, andmake your changes.

Table 15-3. CDE System and User Configuration Files

Nature of Configuration File	System-Wide Influence	User's Personal Influence
Environment Variables	/usr/dt/config/	$HOME/
Appearance &Behavior Resources	/usr/dt/config/C /usr/dt/app-defaults/C	$HOME/.dt/ $HOME/.dt/sessions/current/ $HOME/.dt/sessions/home/
File Types &Action Definitions	/usr/dt/appconfig/ types/C	$HOME/.dt/types
Client Startup at Login	/usr/dt/config/ /usr/dt/config/C	$HOME/.dt/session/ $HOME/.dt/session/current/ $HOME/.dt/session/home/
Workspace Manager	/usr/dt/config	$HOME/.dt/

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 to be used and the incorrect value to be 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 value is used.

• For data types, the first specified value is used.

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

Table 15-4. What CDE Uses for Configuration

Configuration Element	Element Used
resource	last encountered or most specific
environment	last encountered
action	first encountered
file type	first encountered

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, 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.

The Sequence of Events When CDE Starts

The following section is a blow-by-blow account of what happens when a user logs into CDE. In this particular account, assume a distributed topology like a diskless cluster. The account begins with the boot of the hub system and nodes in step 1. By step 4, X servers are running on each node and login screens are being displayed. By step 6, the user is logged in. By step 11, the session manager is busy re- creating the user's session.

1. The dtlogin executable is started as part of the init process that occurs during the system boot sequence on the hub machine and each cluster node.

2. dtlogin reads /usr/dt/config/Xconfig to get a list of resources with which to configure the login process. This is where dtlogin first learns about files such as Xaccess, Xservers, Xresources, Xstartup, Xsession, and Xreset and gets the values of a number of appearance and behavior resources.

3. dtlogin reads two files in /usr/dt/config:

   • Xservers or the file identified by the Dtlogin*servers resource setting in Xconfig.

   • Xresources or the file identified by the Dtlogin*resources resource setting in Xconfig.

4. dtlogin starts an X server and a child dtlogin for each local display.

5. Each child dtlogin invokes dtgreet, the login screen.

6. When a login and password are validated, a child dtlogin sets certain environment variables to default values.

7. The child dtlogin runs /usr/dt/config/Xstartup.

8. The child dtlogin runs /usr/dt/config/Xsession.

9. Xsession runs dthello, the copyright screen.

10. Xsession reads $HOME/.dtprofile, setting any additional environment variables or overwriting those set previously by dtlogin.

11. The child dtlogin invokes the session manager, dtsession.

12. dtsession restores the appropriate session. For example, to restore the current session, dtsession reads dt.resources and dt.session in $HOME/.dt/sessions/current.

At logout, the reverse happens. The session is saved and dtlogin runs /usr/dt/config/Xreset. After Xreset completes, dtlogin again displays the login screen as in step 4.

CDE and Performance

CDE isn't a monolithic application; it's a set of components layered on top of the operating system, the X Window System, and Motif. Each underlying layer takes its share of RAM before CDE or any other client even starts. Because of the low-level nature of these layers, the RAM they use is hardly ever regained through swapping to disk.

In some cases, operating system overhead and user application requirements restrict the amount of RAM available for a graphical user interface to little more than enough to run a window manager such as Motif. Because the CDE workspace manager and the Motif window manager take roughly the same amount of RAM, users can enjoy an enriched graphical environment with the added value of CDE's multiple workspaces at essentially no extra RAM cost over running the Motif window manager.

Tactics for Better Performance

Unless all your users have RAM-loaded powerhouses for systems, you will need to spend some time developing a performance strategy. If you conceive of performance as a bell-shaped curve, satisfaction lies on the leading edge. Your performance strategy should do everything it can to keep your users on the leading edge.

Probably the most logical approach is to start small and grow. In other words, start out with minimal user environments on all the systems on your network. Gradually add software components until you or your users begin to notice performance degradation. Then back off a little. Such an approach might take several weeks or more to evaluate, as you add components and as your users spend several days actually working in the environment to determine the effect of your changes on system performance and their frustration levels.

The most RAM-expensive pieces of CDE are the workspace manager, the session manager, and the file manager. The workspace manager is expensive because portions of it are always in RAM (assuming that you are moving windows around and switching workspaces). The CDE workspace manager is no more expensive than the Motif window manager; if you want a GUI, it's just a price you have to pay. The session manager is expensive only during logout and login, because it saves and restores sessions. The rest of the time, the session manager is dormant and gets swapped out of RAM. Saving your current work session is nice at the end of the day, but it's something to consider giving up if you want to improve your login and logout performance. The file manager is expensive because it wakes up periodically and jumps into RAM to check the status of the file system and update its file manager windows. When it jumps into RAM, it pushes something else out, for example, maybe the desktop publishing program you're using.

Here are some other ideas that you may find useful:

Terminal Emulators	xterms are a little less RAM-expensive than dtterms. Unless you need the block mode functionality of a dtterm, xterm might be a better choice for terminal emulation.
Automatic Saves	Some applications automatically save data at periodic intervals. Although this feature can be beneficial, you need to evaluate its effect in the light of performance. If the application is central to your users' work, fine, but if not, you might want to disable the automatic save feature.
Scroll Buffers	Large scroll buffers in terminal emulators can be a real convenience, but they can also take up a lot of RAM. Even modestly sized scroll buffers, when multiplied by three or four terminal emulators, consume a lot of RAM.
Background Bitmaps	Avoid large bitmaps; they increase the X server size. Especially avoid switching large bitmaps frequently within a session. If you are hunting for a new background, be sure to restart the X server after you've found the one you want and have included it in the proper sessionetc file. The most efficient bitmaps are small ones that can be repeated to tile the background.
Front Panel	Reconfigure the front panel to minimize the number of buttons. Keep just enough to meet user needs. This tactic decreases the workspace manager size in RAM and speeds login and logout.
Pathnames	Whenever possible, use absolute pathnames for bitmap specifications. Although this approach decreases the flexibility of the system, it speeds up access time.

Conclusion

The default CDE is ready to use, but given its power and flexibility, you will inevitably want to customize the CDE environment for your users' work context and optimum performance. Take the time to develop a good idea of what changes you need to make, the order in which to make them, and exactly where to make them. In so doing, all the power and flexibility of CDE will be open to you.

CONTENTS