HP OpenVMS Systems Documentation |
Common Desktop Environment: Advanced User's and System Administrator's Guide 4 Registering an ApplicationContents of Chapter: This chapter describes how to create a registration package for an application and how to register the application onto the desktop. When an application is fully registered onto the desktop, it has:
Overview of Application RegistrationThis section explains:
Note: For a detailed example that shows how to register an existing application, see "Example of Creating a Registration Package". Features Provided by Application RegistrationApplication registration provides a graphical way for users to:
The Purpose of Application RegistrationA registered desktop application has certain configuration files used by the desktop to provide the application's user interface:
It can be difficult to administer an application when its configuration files are scattered among numerous directories. Therefore, the desktop allows an application to keep all its desktop configuration files gathered under a single directory. This grouping of files is called a registration package. If the application is desktop smart, it supplies a registration package as part of its installation package. If you are a system administrator creating the configuration files yourself, you can create the registration package yourself. The configuration files in the registration package are not available to the desktop because they are not located in the proper search path directories. The process of placing these files in the proper locations is called registering, or integrating, the application. The desktop provides a tool, dtappintegrate, that performs the registration by creating symbolically linked representations of the files in the proper search path directories. Many desktop-smart applications will automatically run dtappintegrate during the installation process. If you are a system administrator integrating an existing application, you can run it yourself after you've created the registration package. Once an application is registered on a system's desktop, the application is available to all users on the system. If the system is configured as a desktop application server, the application will also be available to other systems throughout the network. The dtappintegrate tool has a command-line option that reverses the process by breaking the links. This makes it easy to remove the application from the Application Manager so that it can be moved to a different application server or updated. General Steps for Registering an ApplicationNote: For a detailed example that uses these steps to create an application package, see "Example of Creating a Registration Package".
Step 1: Modifying Font and Color ResourcesNote: For an example of modifying resources for an application, see Step 1 of the "Example of Creating a Registration Package". The desktop provides mechanisms for setting and manipulating interface fonts and window colors. In order for an application to use these mechanisms properly, you may have to modify the application's app-defaults file. Modifying Font ResourcesNote: This section applies to applications created using OSF/Motif 1.2 (or later versions). Style Manager cannot set interface fonts for applications written using earlier versions of OSF/Motif. The desktop Style Manager will set interface fonts for applications created using OSF/Motif 1.2 (or later versions) if the application does not specify application-specific interface fonts. Style Manager provides two fonts:
/usr/dt/app-defaults/language/Dtstyle. If you want the application to use the Style Manager fonts, you should remove any application resources that interface specify fonts. The desktop will automatically set the application's resources appropriately:
Modifying Color ResourcesStyle Manager provides the ability to change application colors dynamically. The application must be an OSF/Motif 1.1 or 1.2 client. Clients written with other toolkits cannot change color dynamically; color changes take effect when the client is restarted.The easiest way to use the dynamic colors provided by the desktop is to remove any application color resources for background and foreground color. Step 2: Creating the Desktop Application RootNote: For an example of creating the desktop application root directory for an application, see Step 2 of "Example of Creating a Registration Package". The registration package files for the application are grouped beneath a directory called the application root, or app_root. The app_root directory used for the desktop configuration files can be the same directory as the application's installation app_root or some other location. For example, suppose an application is installed under a directory /usr/BTE. This same directory could be used as the app_root for the desktop configuration files. However, if you are integrating an existing non-desktop smart application, it is recommended that you create a different desktop app_root directory. This will prevent the configuration files you create from being overwritten when you update the application. For example, a system administrator might want to create a directory /etc/desktop_approots/BTE as the desktop app_root directory. Step 3: Creating the Registration Package DirectoriesNote: For an example of creating the registration package directories for an application, see Step 3 of "Example of Creating a Registration Package". The registration package is the group of desktop configuration files used by the desktop to provide a graphical interface for the application.
Registration Package ContentsThe desktop configuration files include:
Figure 4-4 A registration package beneath an application root directory
The major categories of configuration fields under the app_root/dt/appconfig directory are:
To Create the Registration PackageCreate these directories. If you are providing language-dependent configuration files, create a separate directory for each language. If you are supplying only one language, put the files in the C directory.
Figure 4-5 Application group at the top level of the Application Manager
The dtappintegrate tool operates only on the desktop configuration files in the types, help, icons, and appmanager directories. The application's binary executable, app-defaults, and message catalog files are administered separately. Step 4: Creating the Actions and Data Types for the ApplicationNote: For an example of creating the actions and data types for an application, see Step 4 of "Example of Creating a Registration Package". Actions and data types provide a user interface for the application.
Actions and Data Types Required by an ApplicationTypical applications require the following action and data type definitions:
Location for Action and Data Type Definition Configuration FilesActions and data types are defined in configuration files. The only naming requirement for files containing action and data type definitions is that they must have a .dt suffix. By convention, you may want to name the file action_name.dt or application_name.dt.Place files containing actions and data types under the application root in the directory app_root/dt/appconfig/types/language. The default language is C. Figure 4-6 Action and data type definition files
Ways to Create Actions and Data TypesYou can create action and data type definitions for an application in either of two ways:
To Create Actions and Data Types Using Create ActionThis procedure uses the Create Action utility to create an action and data types for the application.For more information about Create Action, use its online help or see Chapter 9, "Creating Actions and Data Types Using Create Action."
To Create Actions and Data Types ManuallyCreate a configuration file containing the action and data type definitions for the application.Action and data type definition files must follow the naming convention name.dt. You can place all your action and data type definitions in one file or distribute them among multiple files. For each file, use a file name that system administrators will easily connect with your application. Action and data type names must be one word (no embedded spaces). You can use an underscore character. By convention, the first letter of the action or data type name is capitalized. Do not use an existing action name or file name. Use a name that advanced users and system administrators will easily connect with your application. If you want the application's icon labeled with a different name than the action name, include a LABEL field in the action definition. For more information about creating actions and data types, see:
Step 5: Putting the Help Files in the Registration PackageNote: For an example of adding help files to a registration package, see Step 5 of "Example of Creating a Registration Package". If the application includes a desktop help volume (a help volume created with the desktop Help Developer's Kit), the help volume master file (*.sdl) should be placed in the directory app_root/appconfig/help/language. Graphics used by the help files are usually placed in a graphics subdirectory. The graphics must be located in the same directory relative to the master help volume (*.sdl) file as when the help volume was created. If the application does not provide a help volume, you can create one if you have the Help Developer's Kit. There are two levels of integration of a help volume:
Step 6: Creating Icons for the ApplicationNote: For an example of creating the icon files for an application, see Step 6 of "Example of Creating a Registration Package". The desktop provides default icons for actions, data types, and application groups. However, you will probably want to create unique icons for the application. Icons are placed in the directory app_root/dt/appconfig/icons/language. Icons Required for the DesktopThe application uses these icon images on the desktop:
. If you do not provide bitmap files, the desktop maps the color specifications of the pixmap files into black and white. However, this mapping may not produce the appearance you want. For more information about icons, see "Icon Image Files". Step 7: Creating the Application GroupNote: For an example of creating the application group, see Step 7 of "Example of Creating a Registration Package". Once you have created the action and data type definitions for the application, you must create the configuration files responsible for creating what the user actually sees--the application group and its contents. The application group is a directory at the top level of the Application Manager (see Figure 4-1). There are three steps to creating the application group:
Creating the Application Group DirectoryTo create an application group, create the directories in the registration package under appmanager, as shown in Figure 4-7.Figure 4-7 The appmanager directory
Application Group NameThe <appgroup_name> in Figure 4-7 is the name for the application group.Figure 4-8 The application group name (<appgroup_name>)
The name can be any allowable file (directory) name. Use a name that describes the application. Configuring the Application Group To Use a Unique IconThe desktop provides a default application-group icon. However, you will probably want to provide a custom icon.If you want to provide a unique icon for the application group, you must create:
The attributes section of the definition specifies the icon to be used. The criteria section of the definition specifies that the data type be defined to any directory named Media_Tools that is a subdirectory of a directory named appmanager. Figure 4-9 shows the relationship between the application group name and the data type definition. The PATH_PATTERN field in the data type definition connects a unique icon to the application group.
Figure 4-9 How an application group gets a unique icon You should also create an Open and Print action for the application group data type:
OpenAppGroup and PrintAppGroup actions are built-in actions defined in /usr/dt/appconfig/types/language/dtappman.dt. Creating the Contents of the Application GroupThe most important item in the application group is an icon to start the application (an action icon). If the application group contains a suite of applications, there is usually an icon for each application.In addition to one or more action icons, the application group may contain:
Creating the Action File (Application Icon)The application group should contain an icon that launches the application. If the group supplies a suite of applications, there should be an icon for each one. These icons are called application icons, or action icons, since they represent an underlying action.An action icon is created by creating an executable file with the same name as the action it will run:
The file is called an action file, because its purpose is to create a visual representation of the underlying action.For example, if you've created an action named BestTextEditor that runs the BestTextEditor application, you would create an executable file named BestTextEditor. In File Manager and the Application Manager, the action file will use the icon image specified in the action definition. Figure 4-10 illustrates the relationship between the action definition, action file, and actual entry in the Application Manager window. Figure 4-10 The application icon is a file in the application group
Read Me FilesThe desktop provides a README data type that you can use for your application's README files. Use one of these naming conventions:
Creating a Specialized Front Panel ControlIn most cases, you do not need to provide a Front Panel control definition; the user can add the application to the Front Panel by dropping the action icon on the Install Icon control in a subpanel.You might want to create a Front Panel configuration file containing a control definition for your application if you want users to be able to install a control that behaves differently than the action icon--for example, if the control monitors a file and changes appearance when the monitored file changes. Front Panel configuration files are placed in the app_root/dt/appconfig/types/language directory. The naming convention is name.fp. If you supply a configuration file containing a control, the user can add the control to a subpanel by dropping the *.fp file on the Install Icon control in the subpanel. For example, the following definition can be placed in a Front Panel configuration file in the application group. If the user drops this file on an Install Icon control in a subpanel, a control is created in the subpanel that runs a single instance of the BestTextEditor application. If BestTextEditor is already running, the window is moved to the top of the window stack in the current workspace.
For additional information about creating Front Panel configuration files,
see:
Step 8: Registering the Application Using dtappintegrateNote: For an example of registering an application, see Step 8 of "Example of Creating a Registration Package". Once you've created a registration package under an application root, you are ready to perform the actual application registration. Application registration creates links between the registration package and the directories located along the desktop search paths (see "How dtappintegrate Integrates Applications"). To Register an Application with dtappintegrateIf the application is desktop-smart, dtappintegrate is usually run automatically as the final step in the installation process. If it is not run automatically, or if you have created the configuration files to integrate a non-desktop smart application, then you can run dtappintegrate manually.
Syntax and Options for dtappintegrate
How dtappintegrate Integrates ApplicationsThe function of dtappintegrate is to set up links between the installed files and the locations where the desktop looks for configuration files.
Actions and Data Typesdtappintegrate creates symbolic links from the action and data type definition files in the registration package to the system-wide directory along the action database help search path. This is done by creating links from
to
Help Information Filesdtappintegrate creates symbolic links from the help files in the registration package to the system-wide directory along the help search path. This is done by creating links from
to
Icon Filesdtappintegrate creates symbolic links from the icon files in the registration package to the system-wide directory along the icon search path. This is done by creating links from
to
Application GroupTo place the application group for the application into the top level of Application Manager, dtappintegrate creates a link between the application group directory in the registration package and the system-wide location along the application search path. This is done by creating links from the directory
to
Example of Creating a Registration PackageThe following steps create a registration package for an existing, non-desktop smart application named BestTextEditor.
Information You Need to Know About ``BestTextEditor''The example assumes the following facts about the BestTextEditor application:
Steps to Registering ``BestTextEditor''The following step-wise procedure registers BestTextEditor.
|