COMING SOON

THE DISCOVERY JOURNAL OF COMPUTING

Sponsored by:
[KL Group] [Neuron Data] [INT]
[CENTERLINE] [IST] [NTI]
[Java Training]

[Friendly Desktops]

Application Management with CDE

by Rand Schulman

Copyright © 1995-96 Rand Schulman, All Rights Reserved. Used With Permission.


The X Advisor: June 1995 - Vol 1 No 1. http://www.unx.com/DD/advisor/

DISCOVERY PUBLISHING GROUP

Hello and Welcome to the Grand Opening of The X Advisor, the state of the art in digital publishing devoted to the X Window System. As the banner on the cover and TOC pages indicates, this is the definitive journal for X professionals, covering X11, Motif, CDE and related technologies. This is where Friendly Desktops comes in. TriTeal, if anyone is not aware, is at the heart of the CDE standardization and development effort. We produce the CDE core technology which is then implemented by the various vendor implementations of the CDE development partnership.

This article, written by Kevin Underriner, describes application management in CDE. At the time this premiere issue is being published, I am galavanting off on a European tour to meet with several industry leaders and corporate heads to discuss CDE related specifics, thus I have asked Kevin to pinch hit for me until my return. So, without further adieu, take it away Kevin!


Are you tired of users complaining about the complexity of UNIX desktops? Is application integration becoming increasingly more difficult as you install more applications, servers, and workstations? Have you given up on using networked host resources?

Read on. While not a panacea, the Common Desktop Environment (CDE) does provide solutions to the most frequent problems with Application Management on every desktop, UNIX or other.


* * * A D V E R T I S E M E N T * * *


X-Designer is the fastest GUI Builder for Motif and Microsoft Windows. No other tool can match its speed and ease of use.

X-Designer's powerful re-use model enables interfaces to be rapidly built from previous designs. The more you use it, the easier it gets. Re-usable definitions can even be shared across a corporation.

X-Designer generates plain, portable C or C+ code as well as UIL. There are no runtime licenses, libraries or fees and no proprietary code. The C++ generated for Microsoft Windows will work with Windows 3.1, Windows 95 and Windows NT.

X-Designer is recognized as the industry leading GUI Builder. Chosen by Sun, it has won many awards and has been received with great acclaim by users and the press.

"X-Designer applies
an object-oriented
model that promotes
a hierarchical design
and reusability better
than any GUI builder
I've seen."

Information Week
August 7, 1995


X-Designer's Features Include:
  • Advanced Layout Editor
  • Colour Pixmap Editor
  • Support for Drag & Drop
  • Dynamic Window Navigation
  • Support for Building Help in the Interface
  • Compound String Editor
  • OPEN LOOK and UIL Import
  • Third Party Widget Integration
  • Best of all, X-Designer's cross-platform support is included with the standard product, giving the lowest cost of ownership of any comparable builder.



    U.S. Offices
    120 Hawthorne Ave.
    Suite 101
    Palo Alto, California 94301
    Tel: 415-688-0200
    FAX: 415-688-1054
    U.K. Headquarters
    95 London Street
    Reading,
    Berkshire RG1 4QA
    Tel: +44 1734 587055
    FAX: +44 1734 589005

    Click Here For Your FREE Evaluation Copy!

    e-mail: sales@ist.co.uk
    URL: http://www.ist.co.uk


    * * * E N D A D V E R T I S E M E N T * * *


    Launching Applications

    UNIX desktops have historically been less than intuitive for users who want to simply run an application. Most X Window installations utilize both staggered menus and commands that are entered in a terminal window to launch applications. This model is fairly unique to UNIX and is not inherently obvious to users.

    The CDE model is obvious to users. It is based on the models used in many non-UNIX desktops. If you want to run an application, you click on its icon. No more menus and no more obscure command line arguments.

    The icons themselves reside in a variety of locations on the desktop. The most obvious location is the Front Panel (Figure 1). Found at the bottom of the desktop, the Front Panel contains a number of icons. Each icon is called a control and can represent an application. Click on the icon and the application is started.


    [Figure 1. The Front Panel]

    Figure 1. The Front Panel


    [Figure 2. Subpanel]

    Figure 2. Subpanel


    The size of the Front Panel allows roughly a dozen controls. A method of increasing the number of applications available on the Front Panel is to use subpanels (Figure 2). Each control has an optional subpanel which is a pull up window accessed by clicking on the arrow above the icon. The subpanel contains additional controls that represent more applications.

    The Front Panel controls and their subpanels present a straightforward means of accessing applications. However, a site with many applications may find this functionality limited due to the finite number of controls that can reside on the Front Panel and in the subpanels.

    The Application Manager solves this problem (Figure 3). An Application Manager window is a specialized File Manager window. It contains application icons and application group icons. The application icons function in the same manner as those on the Front Panel.


    [Figure 3. Application Manager]

    Figure 3. Application Manager


    The application group icons represent groups of applications. Each group can contain both application icons and additional application groups. This structure allows applications to be organized within the Application Manager both topically and hierarchically.

    The Front Panel and the Application Manager provide the main means of organizing and launching applications. Yet, this may still be a drawback for users who tire of navigating through a multi-level Application Manager window to simply click on an icon that doesn't exist on the Front Panel.

    This too is addressed. Users can drag icons from an Application Manager window and place them directly on the desktop. The icons will reside on the desktop until removed by the user.


    [Figure 4. Install Icon]

    Figure 4. Install Icon


    Additionally, users can install Application Manager icons in the subpanel of their choice. This is done by opening a subpanel and dragging the icon to the top control of the subpanel, labeled "Install Icon" (Figure 4). The icon will then be a part of the subpanel until deleted via the icon's menu which is accessed with the right mouse button.


    [Figure 5. Add Subpanel]

    Figure 5. Add Subpanel


    If a subpanel is already full, users can add a new one to any control that is without. Simply click the right mouse button on a Front Panel control to access the control's menu and select "Add Subpanel" (Figure 5). A new subpanel, containing both the Install Icon control and the control that resides on the Front Panel, is then added above the icon.

    For those users who don't like the additional step of opening a subpanel to access an application, CDE allows interactive modification of the Front Panel content. Any application icon existing in a subpanel can be installed on the Front Panel. Access the subpanel icon's menu with the right mouse button and select "Copy to Main Panel" (Figure 6). The icon then replaces the existing Front Panel control beneath the subpanel.


    [Figure 6. Launching Applications]

    Figure 6. Launching Applications


    The various methods of launching applications in CDE present a suite of new functionality designed to make life easier for both users and administrators. This is good, yet some of you may be required to use the mechanisms that are familiar to your users. These too are available, as the CDE window manager is a superset of mwm. The configurations for root and window menus are virtually identical to those in mwm. Nothing prevents menu driven application launching other than the idea that this method is less than obvious, and better, more functional methods are strongly encouraged.

    Application Manager Details

    An Application Manager window is a File Manager view of a directory. By convention, the contents of the directory are files and directories that have special meanings within the scope of the File Manager view. The special meanings are overrides provided by actions and data types.

    Action and data type definitions are maintained in the Action Database. The File Manager consults the Action Database to determine the details of every object in a directory, including the object's icon and it's functionality. All executable files that have the same name as a defined action are displayed as per the action definition. All other files and directories are displayed as per the appropriate data type definition.

    The content of any file that has been overridden by an action is irrelevant. Once the File Manager has determined that a file is an action, the definition of the action dictates its functionality.

    There are two types of actions, commands and messages. Command actions run applications. Message actions send a message to ToolTalk which can pass information to other applications or start an application that is registered with ToolTalk.

    An example of a very simple command action is the following:


    ACTION BlueXterm 
    { 
    	TYPE COMMAND 
    	EXEC_STRING xterm -bg blue 
    	ICON BlueXterm 
    	WINDOW_TYPE NO_STDIO 
    } 
    

    This creates the action named BlueXterm that when run executes an xterm with a blue background. The WINDOW_TYPE field indicates that the command should not be run in a separate controlling terminal window.

    All files that are not actions are displayed as per their data type. A data type definition specifies the attributes of an object (e.g. its appearance) and the criteria under which the attributes apply (e.g. the path name).

    In an Application Manager window we are only concerned with the data type definitions that apply to the application groups. An application group is a directory. The data type definitions for application groups specify that a directory with a certain name should be shown with a special icon rather than the normal directory icon.

    Building an Application Manager Window

    The default Front Panel shipped with CDE has a control that opens a preconfigured Application Manager window. This window (Figure 3) displays the contents of the directory /var/dt/appconfig/appmanager/$DTUSERSESSION. The DTUSERSESSION environment variable is set during session initialization and has the following value:

    	login-hostname-display# 
    

    Where login is the user's login name, hostname is the machine they logged in to, and display# is the X server display number of the login session.

    Also during session initialization, the dtappgather command populates the DTUSERSESSION directory based on the value of the DTAPPSEARCHPATH environment variable. By default, DTAPPSEARCHPATH is a comma separated list of the following directories:

    	$HOME/.dt/appmanager 
    	/etc/dt/appconfig/appmanager/locale 
    	/etc/dt/appconfig/appmanager/C 
    	/usr/dt/appconfig/appmanager/locale 
    	/usr/dt/appconfig/appmanager/C 
    

    All files and directories found in each of the directories listed in DTAPPSEARCHPATH are linked to the DTUSERSESSION directory by dtappgather.

    The three directories in DTAPPSEARCHPATH allow applications and application groups to be "gathered" in an hierarchical manner from:

    Application Manager windows are not limited to the methods provided by default. The mechanisms described above can be disabled or modified by changing the session initialization routines. The default mechanisms simply provide a model that should be appropriate for most installations.

    The Network is the Computer?

    Hmmm... sounds good, however in practice distributed computing has been severely limited by the complexities involved with configuring applications to use network based resources. The CDE application management model simplifies both the configuration and administration of network resources, thus enabling the network to be the computer.

    CDE allows applications to be configured for both local and network based (remote) execution. The model for either configuration is identical, requiring nothing other than the modification of an environment variable that is used to build the Application Manager.

    By default, the Application Manager contains the local applications. The addition of the remote host name in a single environment variable causes the Application Manager to include all of the applications available on the remote host.

    During the initialization of a session, the command dtsearchpath is run to build the search path environment variables, such as DTAPPSEARCHPATH. dtsearchpath uses "input" environment variables to generate the "output" search path. The input environment variables specify remote host information to include in a search path.

    DTAPPSEARCHPATH is constructed from the default locations and the two application host environment variables DTSPUSERAPPHOSTS and DTSPSYSAPPHOSTS. Their value is a comma separated list of locations, where a location has the syntax:

    /path Specifies a directory on the local system.

    hostname: Specifies the system directory (/etc/dt/...) on the remote machine hostname.

    hostname:/path Specifies the directory path on the remote machine hostname.

    localhost: Specifies the local system directory (/etc/dt/...)

    dtsearchpath uses the following precedence when creating DTAPPSEARCHPATH:

    Thus, by using the application host environment variables, the Application Manager window can contain application icons and application group icons that reside on a remote host. Is it really this easy? Almost ...

    Recall that an Application Manager window contains actions, which are files that represent an object defined in the Action Database. In addition to including the action representations, the Action Database must include the action definitions.

    The Action Database is built by reading action and data type definitions that reside in configuration files. The locations of the configuration files are listed in the environment variable DTDATABASESEARCHPATH. By default, these locations are:

    	$HOME/.dt/types 
    	/etc/dt/appconfig/types/locale 
    	/etc/dt/appconfig/types/C 
    	/usr/dt/appconfig/types/locale 
    	/usr/dt/appconfig/types/C 
    

    dtsearchpath uses the default locations, DTSPUSERAPPHOSTS and DTSPSYSAPPHOSTS, and the two database host environment variables DTSPUSERDATABASEHOSTS and DTSPSYSDATABASEHOSTS to build DTDATABASESEARCHPATH. The precedence used to build DTDATABASESEARCHPATH is:

    Now that we see how to include remote resources in an Application Manager and the Action Database, how do we force the action to execute on the host where it was defined. This is the easiest part. All actions, by default, run on their "definition" host. If the configuration file containing an action's definition was obtained from a remote system, that system is the default execution host for the action.

    This model may seem complicated due to the sheer number of environment variables. Let's dispel this with an example.

    The host dbsvr contains a database and a suite of database applications. The action definitions are in the directory /etc/dt/appconfig/types/C on dbsvr. The Application Manager action representations are in the application group "Database Applications" under the directory /etc/dt/appconfig/appmanager/C on dbsvr.

    It is a requirement that all of the actions in the "Database Applications" group run on dbsvr. It is a requirement that all users have access to the Database Applications group.

    This is accomplished by setting the following during a user's session initialization:

    DTSPSYSAPPHOSTS=dbsvr:

    That's it.

    Once again, is it really this easy? Almost...

    The seamless integration of remote servers and their resources requires certain operating system level configurations. It is necessary for the following to be true:

    It is also strongly recommended that the following are true in order to simplify action configuration and functionality:

    Conclusion

    When you consider the advantages inherent with the remote services provided by the CDE model, any inconveniences generated by reconfiguring the filesystem and user configurations become insignificant.

    CDE is here and presents a level of desktop functionality never before accomplished. The Application Management model provides users, administrators, and integrators with solutions to their most common problems, while increasing the capability of your networked resources.


    Rand Schulman is a founding employee, former Sr. VP and General Manager for Island Graphics. He has 13 years' experience with UNIX software, the last 3 as Vice President of Sales & Marketing for Pages Software. He is currently head of Marketing for TriTeal and may be reached via email at rand@triteal.com.

    Kevin R. Underriner is a Field Systems Engineering Manager with the TriTeal Corporation. He can be reached at kevin.underriner@triteal.com.


    We really want to know! How would you rate this article, and why?
    No Opinion Excellent Good Fair Poor

    Send comments to rand@triteal.com or webmaster@unx.com.
    Column Master TOC

    We want YOU to write an article for us!

    WebCrafting | TXA Back Issues | CPS Back Issues |
    Mail | Search


    This page and all its contents are Copyright ©1994-1996 NetCast, Inc., USA, All Rights Reserved.
    The X AdvisorTM, Cross Platform SolutionsTM WebCraftingTM, and JavaTalkTM are all trademarks of NetCast, Inc.

    Steve MikesTM, Steven MikesTM, and UNX TechnologiesTM are trademarks of UNX Technologies, Inc.