The Purpose of Application Registration

A registered desktop application has certain configuration files used by the desktop to provide the application's user interface:

Action and data type definition files
Icon image (pixmap or bitmap) files
A directory and files that create the application group
Optionally, desktop help files and Front Panel definition files

In order for these files to be recognized and used by the desktop, they must be in certain directories specified by the desktop's search paths.

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 Application

Note - For a detailed example that uses these steps to create an application package, see "Example of Creating a Registration Package".

Modify any application resources that set fonts and colors. Otherwise, the desktop's dynamic fonts and colors will not work properly.
See "Step 1: Modifying Font and Color Resources".

Create an application root location.
See "Step 2: Creating the Desktop Application Root".

Create the directory structure underneath the application root.
See "Step 3: Creating the Registration Package Directories".

Create the actions and data types for the application.
See "Step 4: Creating the Actions and Data Types for the Application".

Put the help files in an appropriate directory.
See "Step 5: Putting the Help Files in the Registration Package".

Create the icons for the application
See "Step 6: Creating Icons for the Application".

Create the application group for the application.
See "Step 7: Creating the Application Group".

Register the application using dtappintegrate.
See "Step 8: Registering the Application Using dtappintegrate".

Step 1: Modifying Font and Color Resources

Note - 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 Resources

Note - 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:

system font--used by system areas such as labels, menus, and buttons

user font--used for editable areas such as text fields

Each font is provided in seven sizes, labeled 1 through 7 in the Fonts dialog box. The Style Manager fonts are connected to actual fonts on the system through Style Manager resources set in /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:

FontList--set to system font

XmText*FontList--set to user font

XmTextField*FontList--set to user font

Modifying Color Resources

Style 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 Root

Note - 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, 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 Directories

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


5. Registering an Application Overview of Application Registration Features Provided by Application Registration


	The Purpose of Application Registration A registered desktop application has certain configuration files used by the desktop to provide the application's user interface: Action and data type definition files Icon image (pixmap or bitmap) files A directory and files that create the application group Optionally, desktop help files and Front Panel definition files In order for these files to be recognized and used by the desktop, they must be in certain directories specified by the desktop's search paths. 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 Application Note - For a detailed example that uses these steps to create an application package, see "Example of Creating a Registration Package". Modify any application resources that set fonts and colors. Otherwise, the desktop's dynamic fonts and colors will not work properly. See "Step 1: Modifying Font and Color Resources". Create an application root location. See "Step 2: Creating the Desktop Application Root". Create the directory structure underneath the application root. See "Step 3: Creating the Registration Package Directories". Create the actions and data types for the application. See "Step 4: Creating the Actions and Data Types for the Application". Put the help files in an appropriate directory. See "Step 5: Putting the Help Files in the Registration Package". Create the icons for the application See "Step 6: Creating Icons for the Application". Create the application group for the application. See "Step 7: Creating the Application Group". Register the application using `dtappintegrate`. See "Step 8: Registering the Application Using dtappintegrate". Step 1: Modifying Font and Color Resources Note - 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 Resources Note - 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: system font--used by system areas such as labels, menus, and buttons user font--used for editable areas such as text fields Each font is provided in seven sizes, labeled 1 through 7 in the Fonts dialog box. The Style Manager fonts are connected to actual fonts on the system through Style Manager resources set in `/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: `FontList`--set to system font `XmTextFontList`--set to user font `XmTextFieldFontList`--set to user font Modifying Color Resources Style 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 Root Note - 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, 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 Directories Note - 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.