Chapter 18. Customizing the Graphical Interface

This chapter contains both the guide and reference information necessary to customize the graphical user interface.

Introduction

Group Files and Item Definitions

Customizing the graphical interface involves editing group files. A group file (.grp) defines a set of named operations — a menu. A group file's scope declaration determines exactly where the menu appears in the interface — file browser toolbar, pulldown menu, vtree browser popup menu, and so on.

Each group file entry, or item definition, defines a single menu item. These menu items typically have names like checkout or merge, but there are no inherent restrictions; labels and operations can be entirely unrelated to ClearCase. You can customize any menu item to perform any operation expressible as a shell script.

The “meat” of an item definition is a function call, command line, or shell script (several of these can be combined in one item definition). An item definition can also specify multi-state icon bitmaps, a menu mnemonic, whether to execute in the background, and so on.

Editing the Predefined Group Files

The default, predefined group files are installed in /usr/atria/config/ui/grp. You should not edit these files in place. It is also not advised to copy and edit them elsewhere — they amount to “source code”; future ClearCase enhancements and bug fixes will leave you behind.

To add your own menus, create new group files in the .grp subdirectory of your home directory ($home/.grp:/usr/atria/config/ui/grp is the the default group file search path). Alternatively, specify a group file search path with the environment variable grp_path, and do your customization work in any of its component directories. Copy to your work area the predefined group file template /usr/atria/config/ui/grp/user.grp.template, and use it as a template for your own work. (This template is scoped to the Fast menu, so you can use your additions as pulldown menus or add them to the toolbar as “push buttons”. See “Scope” for details.)

Upcoming sections describe group file contents in detail. Look ahead to “Customization Procedures” for more recommendations regarding the customization process.


Note: If you are responsible for implementing or maintaining the graphical interface for a group of people, make your group file customizations in one or more globally accessible directories and see that each user's grp_path environment variable gets set accordingly. Also, note that you can use grp_path to control which menus are visible to which users.


How xclearcase Processes Group Files at Startup Time

The default search path for group files is $home/.grp:/usr/atria/config/ui/grp. You can override this search path with the environment variable grp_path. The grp_path can include any combination of directories and files.

When you start xclearcase, it traverses the group file search path, collects all group files, and caches them in ASCII-sorted order. (This determines the order in which pull-down menus appear on the menubar.) If a group file has syntax errors, messages appear in the transcript pad, and all or part of the group file is ignored. If xclearcase encounters more than one group file with the same leaf name, it uses the first one found (permitting you to “eclipse” a group file with one of your own).

Using the cached group files, xclearcase builds the menubar, toolbar, and popup menus for various browser classes.

Group File Syntax

First, let's look at a group file. Figure 18-1 shows a file browser and its menus, which are defined by group files. The Basic pulldown menu is defined by the group file basic.grp, which appears in Figure 18-2.

Figure 18-1. A File Browser and Some Menus


Figure 18-2. A Sample Group File, basic.grp


Although the basic.grp file and Basic menu are fictitious, they illustrate the structure and function of group files.

Syntax Summary

You may have noticed similarities between group file syntax and that of X window manager startup files like .mwmrc or .twmrc. As in a .mwmrc file, the ! and # characters can begin comment lines, and an unquoted, un-escaped # in any column comments the rest of the line. The backslash (\) escape character doubles as the line continuation character.

The file begins with a Scope definition. (Scope is described below.) Each group file defines exactly one primary menu and names it with a RootMenu declaration. The RootMenu declaration is followed immediately by a line containing only an open brace character ({). Submenus, if there are any, are named with Menu declarations.

Each menu item definition is a single logical text line that includes, in order:

  • a label

  • optional bitmap files (for toolbar items)

  • an optional menu mnemonic

  • an optional preselect clause

  • an optional ampersand (&), to run a menu item's command operation in the background

  • one or more f-dot functions — usually an execution string

  • a “popup” help text string

The menu declaration ends with a closed brace character (}).

You may also have observed that the execution scripts, or f.exec strings, in basic.grp contain unfamiliar uppercase keywords, prefixed with the % character. These are ClearCase macros, inserted to perform specialized tasks, like prompting the user for more data or redirecting output to a browser. An input macro, like %pname, can serve two functions: (1) to prompt for interactive input, and (2) as a preselect clause, which specifies the conditions necessary to activate the menu item.

Figure 18-3 restates these rules.

Figure 18-3. Group File Syntax


The following subsections describe first the Scope and RootMenu declarations that begin a group file, and then, the individual components of an item definition.

Scope

Scope browserClass [, browserClass ]... : menuType [ , menuType]... 

Each menu — pulldown, popup, or toolbar — corresponds to a .grp file. The menu definitions (.grp files) all have the same structure and syntax, but they have different scopes. A menu can have one of four basic scopes:

Fast:pulldown  


The menu is accessible from the Fast pulldown menu on the main panel. Menus with this scope can be duplicated (at runtime) as a static menu of buttons below the iconic toolbar.

browserClass:pulldown 


The group appears as a stand-alone pulldown menu on any browser of class browser (file, xxtype, vtree, and so on).

browserClass:popup 


The group appears as a popup menu when the user presses rightMouse on any browser of class browser. You can scope only one menu as any browser's pop-up (the first one found wins).

browserClass:toolbar 


The group appears as a toolbar on any browser of class browser. You can scope only one menu to any browser toolbar (the first one found wins).

The browserClass is one of the following as shown in Figure 18-4:

Figure 18-4. browserClass Listing


The menuType is one of:

pulldown
popup
toolbar

If a menu has no scope specifier, it defaults to *:pulldown and, therefore, appears as a pulldown menu on all browsers.

For example, the ClearCase-supplied group file file_popup.grp begins with the following line, which defines it as the popup menu for all file browsers:

Scope File:popup

Popup and Toolbar Scopes

For any browser class, only one menu can be explicitly scoped to the toolbar or pop-up menu. (See “Fast Menu Scope” to learn how to create a pull-down menu that can be appended to the toolbar.) If you choose to replace a browser's toolbar or pop-up menu, follow the procedure described in “Replacing an Existing Menu”. If you depart from this procedure, and use a group file with a different name than the standard menu, make sure the new file name sorts ahead of the existing one; xclearcase ASCII-sorts group files when it first reads them in.

Fast Menu Scope

The Fast scope is compatible only with menu type pulldown; Fast:popup and Fast:toolbar scopes have no effect.

The Fast menu appears only on the file browser that comes up when you execute xclearcase. It does not appear at all if no menu is scoped to it. If you close the original file browser, the Fast menu is lost for the duration of the xclearcase session (even if you start a new file browser with the Filet -> New file browser option on another browser).

The Fast menu's distinguishing feature is the Static menu option that is prepended to each menu scoped there. You can set the Static menu option to duplicate a menu as a set of “fast access” buttons below the file browser's iconic toolbar. (You could scope your “fast access” menu to File:toolbar, but since only one group file can be scoped to a browser's toolbar, the standard iconic toolbar would be displaced.)

Typical usage — “Pick and choose” a set of commonly used menu items from elsewhere in the interface, and collect them together as a “fast access” menu scoped to Fast:pulldown. When constructing the “fast access” menu, use the f.alias function to clone menu items that reside elsewhere in the interface.

Figure 18-5, Figure 18-6, Figure 18-7, and Figure 18-8 illustrate the results of scoping group files, respectively, to File:pulldown, File:toolbar, File:popup, and Fast:pulldown.

Figure 18-5. Basic Menu Scoped to File:pulldown


Note that it is the file name, not the menu name, that determines where in the menubar the View menu appears.

Figure 18-6. Basic Menu Scoped to File:toolbar


Figure 18-7. View Menu Scoped to File:popup


Figure 18-8. View Menu Scoped to Fast:pulldown


RootMenu Name

RootMenu menuName [ _mnemonicChar ]

For menus scoped pulldown, the RootMenu name is the character string that actually appears in the interface. The RootMenu name has no effect on menu location; that is determined by sorting the names of the group files themselves (See “How xclearcase Processes Group Files at Startup Time”.) See also “Menu Mnemonics” for details on specifying an optional menu mnemonic character.

Item Labels

label [ bitmaps ] [ mnemonic ] [ preselectClause ] [ & ] function [ f.help "text" ]
"label string" or no-label

Item labels are quoted character strings (labels without blanks do not require quotes, but they are recommended for consistency). If the item is scoped to a toolbar, and its definition includes bitmaps, then the item label is not visible in the interface. In all other cases, this is a user-visible label for the menu item. Use no-label to suppress a label — with f.separator, in particular.

Bitmaps

label [ bitmaps ] [ mnemonic ] [ preselectClause ] [ & ] function [ f.help "text" ]
@unarmedFilename[,armedFilename[,insensitiveFilename]]

You can specify bitmap icons for RootMenu menu items scoped to a toolbar. Bitmaps for submenu items, or for items not scoped to a toolbar, are ignored.

The first two bitmaps represent the “unarmed” and “armed” (depressed) states. These two states correspond to “off” and “on” for two-state toggle buttons. (See the builtin function descriptions in section “f.call”.) The third bitmap is displayed when the item is insensitive, or “greyed out”. A toolbar button with a preselect clause needs all three bitmaps.

Bitmaps supplied in item definitions must be stored in /usr/atria/config/ui/bitmaps; otherwise, they must be full pathnames (including suffixes). Do not confuse toolbar bitmaps with file browser icons, which are managed as described in cc.icon (and in the section “Icon Display in the File Browser”).

Menu Mnemonics

label [ bitmaps ] [ mnemonic ] [ preselectClause ] [ & ] function [ f.help "text" ]
_character

The underscore character is required; character is a single, printable character, which must occur in the label string. The first occurrence of character in the label string is underlined — but only if the character's letter case (upper or lower) matches the case in which it appears in the label string.

Menu mnemonics enable keyboard access to menus and menu items. See Table 3-2 in Chapter 3, “Using the ClearCase Graphical User Interface,” for a description of how menu mnemonics are used to navigate menus.

A mnemonic character has no meaning for an item or menu scoped to a toolbar.

Preselect Clauses

label [ bitmaps ] [ mnemonic ] [preselectClause ] [ & ] function [ f.help "text" ]
% dataType[preselect-count](restrictions)

The preselect clause defines the conditions necessary to activate the menu item. The item is “greyed out” until the user selects at least one object that satisfies the preselect clause. If there is no preselect clause, the button or menu option is always enabled.

  • A preselect clause has three parts:

  • a single data type (or input macro) keyword; see “Input Macros” for a information on how to construct this piece of a preselect clause.

  • an optional “how many?” specifier, inside square brackets, which specifies the number of applicable data items the user must preselect in order to enable the menu item; some representative examples:

    none 

    user must preselect exactly one item

    [] 

    same as [1+]; user must preselect one or more items

    [2] 

    user must preselect two items

    [2+] 

    user must preselect two or more items

    [2-4] 

    user must preselect between two and four items, inclusive

    [0+] 

    no preselection requirement

    [0] 

    no preselection permitted (item not enabled if any data is selected)

  • a parenthesized list of restrictions (see the restrictions arguments to the various input macros in the section “Input Macros”). The actual restrictions are optional; the parentheses are not.

Preselect clauses are closely linked to the %selection macro. If an item definition includes a preselect clause, its execution script includes at least one %selection macro, which is replaced by the preselected data at execution time.

You cannot have the user preselect multiple data types (three pathnames and two label types, for example). If your menu item operation requires multiple kinds of data, or it requires data items in a particular sequence, you can get only one type of data, or one argument, via preselection. You must use one or more additional mechanisms to collect the remaining input; xclearcase input macros and clearprompt exist for this purpose.

Background or Foreground Processing

label [ bitmaps ] [ mnemonic ] [ preselectClause ] [ & ] function [ f.help "text" ]
&

Include an ampersand character to have the menu operation execute in the background. When a script executes in foreground mode (no &, the default), the watch cursor blocks other commands until the currently executing f.exec script (or f.call) is complete.

For backgrounded item definitions, all f.exec scripts except the last one behave like foreground scripts. The last (or only) f.exec script runs in the background. Any f.call functions that follow the last f.exec run in the foreground, without waiting for the f.exec to complete.

F-dot Functions

label [ bitmaps ] [ mnemonic ] [ preselectClause ] [ & ] function [ f.help "text" ]

Each item definition includes at least one of the following functions in Table 18-1.

Table 18-1. Group Item Functions

F-dot
Function

Argument

Description

f.alias

aliasedItem

Duplicate an existing menu item.

f.call

builtinCall

Call a built-in function.

f.exec

execString

Execute the command or shell script when the button is pressed or menu option selected.

f.separator

none

Insert a dividing line in the group menu.

f.menu

submenuName

Specify a submenu (“cascading” menu).

f.help

helpString

Specify help text for item.

Quoting — The argument to any f-dot function can be quoted with either %QUOTE% keywords or quote characters (""). %QUOTE % keywords permit unescaped quote characters (") to appear in the argument. See also “Group File Processing and Macro Expansion”.

f.alias

f.alias "groupFileLeafName/menuSpecifier/itemLabel"

Duplicates an existing menu item from another group file. An “aliased” item inherits the following characteristics from an existing menu item definition:

  • preselect clause

  • foreground/background execution specifier

  • all f-dot functions (f.calls, f.execs, f.menu, f.help, f.title, f.alias)

example as shown in Figure 18-9 (from file_popup.grp)

Figure 18-9. f.alias Example



Note: The menu name root in the second example. Use root if the menu item is defined in the target group file's RootMenu.

You cannot override f-dot functions in the alias definition. Also, an f.alias function cannot be combined with other f-dot functions.

f.call

f.call "builtinFunction"

Calls one of the built-in xclearcase functions. Many of these calls toggle browser display parameters. (See /usr/atria/config/ui/grp/file_pulldown_G_options.grp, for example).

There are also calls to invoke or “pop up” each of the xclearcase browsers. Others perform miscellaneous operations, like closing a browser or quitting xclearcase.

If the builtinFunction call includes an argument with literal quotes, quote the call with %QUOTE% keywords, instead of quote characters (").

Some of the f.call functions create two-state toggle buttons (rather than “push buttons”) automatically. Figure 18-10 shows iconic and textual examples of two-state toggle buttons

Figure 18-10. Two-state Toggle Buttons (Iconic and Textual)


These builtin calls exist to let you position toggle buttons using the menu scope of your choice. Note that you do not get default graphical icons if you scope a toggle item to a toolbar; supply them in the menu item definition like the ClearCase-supplied group files do.

A “customized toggle button” is any toggle button you create with an f.call whose description in Table 18-3 begins “Enable/disable”. Adhere to the following guidelines to guarantee that the state of a customized toggle button is always predictable:

  • In a single item definition, do not combine a toggle f.call with any other f.calls or f.execs. You may be tempted to try and control multiple parameters from a single menu item. However, because xclearcase frequently adjusts these parameters internally in response to other user operations, the state of a toggle button that controls multiple parameters may become inaccurate with respect to one or more parameters.

  • Do not create two toggle buttons for the same parameter on the same browser, as their states are likely to become confused.

Table 18-2 documents the built-in calls.

Table 18-2. Built-in Calls

Call[a]

Description[b]

Applicable
Browsers

XXTYPE pname

Bring up type browser for VOB identified by pname.

all

CLOSE

Close current browser.

all

FILE directory-pname

Bring up file browser on directory-pname.

all

FILE_DISP_DATE

Enable/disable size and date modified display.

file

FILE_DISP_OWNER

Enable/disable owner and permissions display.

file

FILE_DISP_RULE

Enable/disable config spec rule display.

file

FILE_DISP_TYPE

Enable/disable object type information display.

file

FILE_DISP_VERSION

Enable/disable version information display.

file

FILE_SORT_BY_CHECKO UT

Enable (disable by-rule and by-type)/disable sort- by-checkout for file system objects in file browser.

file

FILE_SORT_BY_RULE

Enable (disable by-checkout and by-type)/disable sort-by-rule for file system objects in file browser.

file

FILE_SORT_BY_TIME

Enable/disable “minor”[c] sort-by-time.

file

FILE_SORT_BY_TYPE

Enable (disable by-rule and by-checkout)/disable sort-by-type for file system objects in file browser.

file

FORCE

Force update of current browser.

all

GRAPHIC

Disable/enable graphic (icon) display mode.

file, vtree

KEYBOARD

Enable/disable the keyboard input box for the current browser.

file, xxtype, pool, VOB-tag, view-tag

LIST_DELETE_SELECTED

Delete selected items from the current list browser.

list

POOL pname

Bring up pool browser on VOB identified by pname.

all

print
output-pname
[pagesize ] [ scale ]

Send PostScript image of vtree to output-pname.
pagesize :=
a0 | a1 | a2 | a3 | a4 | a5 | letter | legal
scale :=
SCALE_TO_PAGE | percentScalingFactor
percentScalingFactor
:= an integer; default = 100

vtree

QUIT

Quit xclearcase.

all

SETVIEW view-tag

Set the process's current working view to

view-tag.

 

all

SHOWTRANS

Bring up the transcript pad.

all

TYPE_DISP_ACTIVE

Enable/disable display of active objects.

xxtype

TYPE_DISP_LOCKED

Enable/disable display of locked objects.

xxtype

TYPE_DISP_OBSOLETE

Enable/disable display of locked-obsolete objects.

xxtype

UPDATE

Update any browsers marked for update. By default, browsers are updated when a GUI command completes, or whenever 15 seconds elapse without any GUI activity.

all

USERNAME

Bring up username browser.

all

VIEWTAG

Bring up view-tag browser.

all

VOBTAG

Bring up VOB-tag browser.

all

VTREE element-pname

Bring up vtree browser on element-pname.

all

VTREE_DISP_ALL_LABEL

Enable/disable all labels display (disabled: max=5).

vtree

VTREE_DISP_ALL_VER

Enable/disable display of all versions (disabled: show “significant” versions only — branch points, labeled versions, and hyperlink endpoints).

vtree

VTREE_DISP_CHECKOUT

Enable/disable display of checked-out versions.

vtree

VTREE_DISP_MERGE

Enable/disable merge arrow display.

vtree

[a] Arguments are required, unless enclosed in brackets ([]).

[b] For two-state toggle functions, the first word in an “enable/disable” pair specifies the state that corresponds to “on” or “armed”.

[c] A “minor” sort parameter applies only to data items within the subsets created by the “major” parameters.

While xclearcase macros are most common in f.exec strings, they can appear in f.call arguments as well. Here is a common example:

f.call "VTREE %SELECTION()"

See the sections “Group File Processing and Macro Expansion” and “xclearcase Macros” for details on xclearcase macros.

f.exec

f.exec %QUOTE%execString%QUOTE%

Executes a command line or command script. The argument to f.exec is an executable command or shell script, enclosed either by double-quotes (" ") or by %quote% keywords.

By default, /bin/sh is used. Include a first line like #!/bin/csh to specify another shell.

In a single item definition, you can combine an f.exec script with one or more additional f.calls and/or f.execs. However, if an f.exec script returns a non-zero exit status, f-dot processing terminates for the current operation.

If the execString includes an argument with literal quotes, quote the execString with %QUOTE% keywords, instead of double-quote characters ("). In general, it is highly recommended that you use %QUOTE% for complicated scripts.

Because xclearcase adds macro expansion to f.exec string processing, quoting and character escaping are different than in ordinary scripts. For details on macro expansion, and on using the specific macro themselves, see the sections “Group File Processing and Macro Expansion” and “xclearcase Macros”.

Environment Variables. If you set the environment variable clearcase_dbg_grp to a non-zero value, xclearcase sends debugging information to the transcript pad when executing commands.

If they are not already set, xclearcase sets the atriahome and grp_path environment variables to their default values when it starts up. (atriahome defaults to /usr/atria; grp_path defaults to $home/.grp:$atriahome/config/ui/grp.) This means you can rely on the existence of these variables when writing scripts.

f.separator

no-label   f.separator

Inserts a separator line in a menu, or breaks the horizontal run of a toolbar button set. As for any item definition, a label is required; use the keyword no-label instead of a quoted label string.

f.menu

f.menu submenuName

Specifies a submenu to include in the current menu or submenu (no effect for a menu scoped to a toolbar). The submenuName specifies a menu that is named in a Menu declaration in the same group file.

Figure 18-11 shows a “cascading” menu — the ClearCase menu, and its submenu Checkouts. Figure 18-12 shows an abbreviated version of the group file that defines the ClearCase menu.

Figure 18-11. Cascading Menu


Figure 18-12. Group File with Cascading Menus



Note: The submenu name, referenced in the f.menu function and in the submenu definition, is not the label that appears in the interface. As with all item definitions, the quoted label string, Checkout Info in this case, is what the user actually sees.


f.help

label [ bitmaps ] [ mnemonic ] [ preselectClause ] [ & ] function [ f.help "text" ]

Specifies help text, which is displayed in a popup window when the user presses rightMouse over the menu item (if it is enabled). It is good practice to supply popup help text for all items that include f.call or f.exec functions. There is no need to supply help for f.menu declarations; users cannot access help text on non-command menu items.

When supplying help text, keep each line under approximately 70 characters, to prevent lines from wrapping in the default-sized “popup help” display window.

If the helpText includes literal quotes, quote the execString with %QUOTE% keywords, instead of quote characters (").

Group File Processing and Macro Expansion

Command script quoting and special character escaping are somewhat different than in standard scripts due to the addition of xclearcase macros (see also “xclearcase Macros”). Three passes are made over your f.exec scripts, two by xclearcase and one by the unix shell:

  1. When xclearcase starts up, it scans all group files to build the menu interface.

  2. When the user selects a menu item, xclearcase expands macros in the item's execution script. (This discussion focuses on f.exec scripts, but applies as well to the less common f.call functions.)

  3. Once xclearcase macros have been replaced with appropriate strings, the command, or command script, is passed to the unix shell, which performs its own substitutions and executes the commands.

If an item definition includes multiple f.exec scripts, each is evaluated and executed separately, first to last.

The template file /usr/atria/config/ui/grp/user.grp.template illustrates many of the quoting, character escaping, and line continuation rules described in this section.

Pass 1: Scan Group Files

When xclearcase starts up, it scans the group files, checks syntax, and configures the various menus.

%quote%

The execution script syntax analysis is simplified if you use %quote% keywords, instead of quote characters ("), to enclose your f.exec scripts. Using %quote% eliminates the need to escape backslash characters (\\n, for example) and quote characters (\") in scripts. Inside %quote% delimiters, there is no escape character, and no need for one.

xclearcase Line Continuation

Recall that an item definition is a single logical line. Therefore, a newline (<nl>) must be escaped with the backslash “line continuation character”, unless it falls inside quotes (", ', or %QUOTE% ).


Note: Continue to use line continuation characters in execution scripts as required by the unix shell.


The xclearcase Escape Character — %

The percent character (%) is the xclearcase macro escape character. It is used to prefix macros, and to escape literal characters that might confuse macro processing — % (percent character) and ) (close parenthesis), in particular. If you want a % character to appear as a literal anywhere in an item definition (label string, prompt argument to an input macro, etc.) you must escape it, like this: %%.

Pass 2: Macro Expansion.

Macro expansion — string substitution — occurs when user selects the menu item. In the case of input macros, macro expansion includes prompting for user input.

During this pass, xclearcase is looking for:

  • the macro escape character, %, which prefixes all xclearcase macros

  • after any macro keyword, the parentheses ( ) that enclose macro arguments

  • within parentheses, the commas that separate macro arguments

If you desire that %, (, or ) characters survive this pass (to appear in a macro prompt string, for example), escape them with the % character, like this: %% %( %).

If a macro argument includes a comma, quote the argument. (All macro arguments are strings, though only a few require explicit quotes.)

Macros can appear anywhere within the quoted f.exec string, and they can be nested as well. Macros are evaluated left-to-right; nested macros are evaluated from innermost to outermost.

Pass 3: Script Execution

Once macro expansion is complete, the unix shell makes pass 3, performing its own standard substitutions and executing the script. By default, /bin/sh is used to execute your f.exec scripts. Include a first line like #!/bin/csh to specify another shell.

Figure 18-13 follows an item definition through all three passes, illustrating how the execution string and its xclearcase macros are processed.

Figure 18-13. How an Item Definition's f.exec String is Processed


xclearcase Macros

We have made numerous references to xclearcase macros. This section describes them more precisely and includes a set of tables to use as a reference.

xclearcase macros provide a specialized but straightforward string-replacement mechanism. The overall syntax rules follow:

  • Nesting — Macros can be nested to 32 levels, which are evaluated from innermost to outermost.

  • Arguments — Character string arguments for prompts and titles need not be enclosed in quotes:

    %PNAME(Source file?,NELEM,file,ENABLE)
    

    This example specifies as a prompt the character string “Source file?”. Titles of browsers can be arbitrary character strings; in particular, they can include < SPACE > characters.

    Extra white space is allowed between the arguments of a macro, even
    < NL > characters. Also see Figure 18-14:

    Figure 18-14. Character String Examples


  • Parentheses — Macro arguments must be enclosed in parentheses. If you omit one or more arguments, you must use commas to indicate the “null” argument(s):

    %PNAME(Source file? ,NELEM,file,ENABLE)
                                     (Four explicit arguments)
    %PNAME(Source file? ,,,ENABLE)   
                          (Four arguments, two of them “null”)
    

    Even if a macro takes no arguments, you must include the parentheses:

    %SELECTION()               (Macro that takes no arguments)
    

  • Square brackets — With input macros only, you can use square brackets to collect multiple data input items. See “Input Macros”.

Table 18-3 lists all the xclearcase macros. The following sections describe the xclearcase macros in detail.

Table 18-3. xclearcase Macros

Macro

Brief Description

 

 

Input Macros

 

%ATTYPE[]()

%BRTYPE[]()

%ELTYPE[]()

%HLTYPE[]()

%LBTYPE[]()

%TRTYPE[]()

Prompt for one or more attribute types

Prompt for one or more branch types

Prompt for one or more element types

Prompt for one or more hyperlink types

Prompt for one or more label types

Prompt for one or more trigger types

%HYPERLINK[]()

Prompt for one or more hyperlink objects

%LIST[]()

Prompt for one or more list browser entries

%PNAME[]()

Prompt for one or more pathnames

%POOL[]()

Prompt for one or more VOB storage pools

%STRING[]()

Prompt for one or more character strings

%USERNAME[]()

Prompt for one or more user IDs

%VIEWTAG[]()

Prompt for one or more view-tags

%VOBTAG[]()

Prompt for one or more VOB-tags

 

 

Modifier Macros

 

%ELEMENT()

Strip version IDs from pathnames

%ELEMSUFFIX()

Add extended naming symbol (

@@) to pathnames

 

%MOUNT()

Convert VOB pathnames to VOB-tags (mount points)

%RELATIVE()

Convert names to relative pathnames

%SETVIEW()

Convert pathnames to view-extended pathnames

%SORT()

Return sorted list of pathnames

%VERMOD()

Convert pathnames to version IDs (branch/version)

%WHICH()

Return filename's full pathname from search path

%WILD()

Expand wildcard characters in a pathname argument

 

 

Output Macros

 

%LISTOUT()

Redirect output to a list browser

%TEXTOUT()

Redirect output to a read-only text window

 

 

Memory Macros

 

%SAVE()

Save a string in a named register for later recall

%REMOVE()

Remove named register storage

%RESTORE()

Restore a saved string from a named register

 

 

Miscellaneous Macros

 

%SELECTION()

Insert pre-selected data in f.exec string

%TMPFILE()

Create a file in /usr/tmp (or in $tmpdir)

%DIR()

Return directory associated with current browser

%NAME()

Return name associated with current browser


Input Macros

Input macros collect input from the user after he or she selects the menu item. Unlike the f.calls (vtree, file, vobtag, and so on) that launch new browsers, an input macro displays a text string prompt, and it does not “return” until the user selects data and presses Ok or aborts the operation with Cancel. Although the user can “interrupt” and perform other operations, the prompting browser waits until its original prompt is satisfied.

An input macro's prompt can appear in multiple browsers. For example, if the user has two file browsers up, a %pname macro's prompt will appear in both, as either is capable of returning the required data. Unlike its f.call counterpart, an input macro does not start a new browser if an appropriate one is already displayed.

Input Macros as Preselect Clauses

Input macros, in abbreviated form, double as the preselect clauses in item definitions. The macro tables that follow below document both uses; in particular, they include the various restriction parameters, which apply when composing both preselect clauses and f.exec scripts.

Input Macros and clearprompt

If your f.exec script calls a second script, which itself requires input from the user, use clearprompt in the second script. Note that some cleartool commands, when run from xclearcase, invoke clearprompt automatically to get user input. For example, a checkin command in an f.exec script uses clearprompt to collect a comment (if neither a comment nor -nc is supplied on the command line).

Input Macros and Keyboard Input

Most input macros have an optional keyboard argument, which you can use to enable keyboard input on the prompting browser. Always supply the ENABLE argument when the operation requires input strings that cannot, or may not, appear on the browser. For example, when defining a “make new directory” menu item, use ENABLE so the user can type in a new directory name.

In addition, you may want to use ENABLE even when the user could “point and click” from a browser; the keyboard input box lets users supply pathnames with wildcards, instead of having to select many individual items. In general, enable keyboard input whenever there is a chance the user will want to type in the required data items.

Input Macros and Browsers

Each ClearCase data type has a corresponding input macro whose job it is to prompt for that type of data as shown in Table 18-4.

Table 18-4. Data Types, Browsers, and Input Macros

Input macro

Kind of data returned by macro

%PNAME()

pathname

%HYPERLINK()

hyperlink

%LIST()

list data

%POOL()

storage pool

%ATTYPE(), %BRTYPE(), %ELTYPE(), %HLTYPE(), %LBTYPE(), %TRTYPE()

ClearCase type object

%STRING()

character string

%USERNAME()

UNIX username
(login name)

%VIEWTAG()

view-tag

%VOBTAG()

VOB-tag

The prompt from an input macro appears at the bottom of the browser display and includes Ok and Cancel buttons. After Ok or Cancel, auto-displayed browsers disappear. In general, browsers stay up when started with an f.call function; otherwise, they come and go as needed to satisfy the input macros in f.exec strings.

Input Macros and Brackets

By default, an input macro seeks exactly one data item, and if the user selects more than one item, the operation fails with a Function not executed error message in the transcript pad.Use the optional square brackets on an input macro to collect multiple data input items. Note that the various numerical specifiers permitted inside brackets in preselect clauses do no apply to input macros.

Input Macros and Restrictions

If the user presses Ok, but the selected data does not satisfy the restrictions argument of an input macro, the transcript pad displays the script and the message Function not executed. (Note that the Ok button is not enabled until the user selects the number of data items that satisfies the [] construct.)

%ATTYPE

%ATTYPE[


preselect-count]( 


restrictions )          preselector
%ATTYPE[](


 prompt,


restrictions,


pname-in-VOB, 


keyboard ) macro
(also: %BRTYPE, %ELTYPE, %HLTYPE, %LBTYPE, %TRTYPE)

Prompt for one or more attribute, branch, element, hyperlink, label, or trigger types (see Table 18-5 and Example 18-1.)

Table 18-5. %ATTYPE Input Macro

Argument

Values

Default

prompt

Character string for user prompt

Select xxx type(s)

restrictions

ACTIVE or LOCK or OBSOLETE

any type object

pname-in-vob

Pathname in any VOB

VOB containing working dir

keyboard

ENABLE

not enabled


Example 18-1. ATTYPE


f.exec %QUOTE%
cleartool mkbranch %BRTYPE(Which branch?,,,ENABLE) %SELECTION()
%QUOTE%

Each xxtype macro invokes a corresponding type browser on a particular VOB. Use the restrictions argument to limit the kind of data that the user can specify:

ACTIVE 

Prompt for (or allow preselection of) type objects that are not locked.

LOCK 

Accept only type objects that are locked.

OBSOLETE 

Accept only type objects that are obsolete. (See the lock manual page.)

%HYPERLINK

%HYPERLINK[preselect-count]( )                    preselector
%HYPERLINK[]( 


prompt,


browser )                          macro

Prompt for one or more hyperlink objects (see Table 18-6 and Example 18-2.)

Table 18-6. %HYPERLINK Input Macro

Argument

Values

Default

prompt

Character string for user prompt

 

browser

vtree element-pname [a]

 

[a] Optional; if you omit it, user is prompted to select an element


Example 18-2. HYPERLINK


f.exec %QUOTE%
cleartool rmhlink \
  %HYPERLINK[](Select merge arrows to remove:,vtree   
  %SELECTION())
%QUOTE%

%LIST

%LIST[preselect-count]( )                         preselector
%LIST[]( 


prompt,


title )                                 macro

Prompt for data from a named list browser (see Table 18-7 and Example 18-3.)

Table 18-7. %LIST Input Macro

Argument

Values

Default

prompt

Character string for user prompt

 

title

Title of list browser to use

 


Example 18-3. LIST


f.exec %QUOTE%
%SAVE(COs,%LIST[](Select items to checkin:,My Checkouts))
cleartool checkin %RESTORE(COs)
%QUOTE%

Use %list to read list data from a named list browser, to which data was previously directed with %listout. (Only the %list macro can read the data in a list browser, and only %listout can create one.) The title argument must match the title used by %listout to create the list browser.

Use the %listout/%list combination when you need to display data and then have the user select from that data. The %listout and %list macros can appear in “back to back” f.exec scripts in the same item definition, or they can appear in separate item definitions — even in separate group files.

A list browser prompts the user to select one or more items (line of text). For each item, only the text preceding the first tab character is returned; any remainder is ignored. Pressing Ok submits the selection; pressing Cancel cancels the entire command operation. The user cannot edit the contents of a list browser.

%PNAME

%PNAME[preselect-count]( restrictions )           preselector
%PNAME[]( 


prompt,


restrictions,


browser,


keyboard )        macro

Prompt (with file or vtree browser) for one or more pathnames (see Table 18-8.)

Table 18-8. %PNAME Input Macro

Argument

Values

Default

prompt

Character string for user prompt

Select pathname(s)

restrictions

DIR or NDIR

ELEM or NELEM

DOBJ or NDOBJ

INVOB or NINVOB

CHECKOUT or NCHECKOUT

RESERVED or NRESERVED

don't care

don't care

don't care

don't care

don't care

don't care

browser

file dir-pname [a]

or

vtree element-pname [b]

file browser prompts for

file in current directory

keyboard

ENABLE

not enabled

[a] file — dir-pname is optional; if you omit it, current working directory is used

[b] vtree — element-pname is optional; if you omit it, user is prompted to select an element

In Example 18-4, the File Browser comes up in /vobs/proj1/src, not in the current working directory.

Example 18-4. PNAME


f.exec %QUOTE%
cleartool checkin \
%PNAME[](Files to checkin,
NDIR ELEM INVOB CHECKOUT RESERVED,
file /vobs/proj1/src)
%QUOTE%

Use the restrictions argument to limit the kind of data that the user can specify:

dir 

all pathnames must be directories

ndir 

all pathnames must not be directories

elem 

all pathnames must be elements

nelem 

all pathnames must not be elements

dobj 

all pathnames must be derived objects

ndobj 

all pathnames must not be derived objects

invob 

all pathnames must be within some VOB

ninvob 

all pathnames must not be within any VOB

checkout 

all pathnames must be checked-out elements

ncheckout 

all pathnames must not be checked-out elements

reserved 

all pathnames must be elements with reserved checkouts

nreserved 

all pathnames must not be elements with reserved checkouts

%POOL

%POOL[preselect-count]( )                         preselector 
%POOL[]( 


prompt,


pname-in-vob,


keyboard )                 macro 

Prompt for one or more storage pool names (see Table 18-9 and Example 18-5.)

Table 18-9. %POOL Input Macro

Argument

Values

Default

prompt

Character string for user prompt

 

pname-in-vob

Pathname in any VOB

VOB containing working dir

keyboard

ENABLE

not enabled


Example 18-5. POOL


f.exec %QUOTE%
cleartool chpool %POOL(Select new pool:,,ENABLE) %SELECTION()
%QUOTE%

%STRING

%STRING[preselect-count]( )                       preselector
%STRING[]( 


prompt,


default )                             macro

Prompt for one or more text lines (see Table 18-11 and Example 18-6.)

Table 18-10. %STRING Input Macro

Argument

Values

Default

prompt

Character string for user prompt

Enter string

default

Character string; pre-fills text input area

 


Example 18-6. STRING


f.exec %QUOTE%
TAG='%STRING(Enter view tag name:)'
STGPNAME='%WILD(%STRING(Enter view storage pathname:,""))'
cleartool mkview -tag $TAG $STGPNAME
%QUOTE%

Use string browsers to prompt for simple text string arguments (for example, comments) or for other data strings— any data that cannot be captured by the more specific data type browsers.

If the %STRING macro includes square brackets, xclearcase may prompt the user for multiple lines of input. When the user presses Ok, the entire contents of the string browser is returned as a single text string: the last line is terminated with <NULL>; all other lines are terminated with <NL>.

%USERNAME

%USERNAME[preselect-count]( )                     preselector
%USERNAME[]( 


prompt,


keyboard )                          macro

Prompt for one or more usernames (see Table 18-11 and Example 18-7.)

Table 18-11. %USERNAME Input Macro

Argument

Values

Default

prompt

Character string for user prompt

Select user name(s)

keyboard

ENABLE

Not enabled


Example 18-7. USERNAME


f.exec %QUOTE%
cleartool lscheckout -user \
  %USERNAME(Specify a user:,ENABLE) %TEXTOUT()
%QUOTE%

%VIEWTAG

%VIEWTAG[preselect-count]( restrictions )         preselector
%VIEWTAG[]( 


prompt,


restrictions,


keyboard )              macro

Prompt for one or more view-tags (see Table 18-9 and Example 18-8.)

Table 18-12. %VIEWTAG Input Macro

Argument

Values

Default

prompt

Character string for user prompt

Select viewtag(s)

restrictions

ACTIVE or INACTIVE

Don't care

keyboard

ENABLE

not enabled


Example 18-8. VIEWTAG


f.exec %QUOTE%
cleartool startview %VIEWTAG()
%QUOTE%

%VOBTAG

%VOBTAG[preselect-count]( restrictions )        preselector
%VOBTAG[]( 


prompt,


restrictions,


keyboard )        macro

Prompt for one or more VOB-tags (see Table 18-9 and Example 18-9.)

Table 18-13. %VOBTAG Input Macro

Argument

Values

Default

prompt

Character string for user prompt

Select vobtag(s)

restrictions

MOUNTED or NMOUNTED

Don't care

keyboard

ENABLE

Not enabled


Example 18-9. VOBTAG


f.exec %QUOTE%
cleartool umount %VOBTAG(,MOUNTED,ENABLE)
%QUOTE%


Note: The default xclearcase interface implements this operation differently:


%VOBTAG(MOUNTED) f.exec "cleartool umount %SELECTION()"

Modifier Macros

Modifier macros take pathname arguments, perform some kind of data manipulation (expansion, extraction, sorting, etc.), and return the resultant text strings.


Note: Unlike input macro arguments, arguments to modifier macros are all required.


%ELEMENT

%ELEMENT( pathnames )                                   macro

Strip any ClearCase annotations from pathnames, leaving standard pathname (see Table 18-11 and Example 18-10.)

Table 18-14. %ELEMENT Modifier Macro

Argument

Values

pathnames

Any pathname(s) (non-element pathnames are returned unchanges)


Example 18-10. ELEMENT


f.exec %QUOTE%
cleartool checkin %ELEMENT(%SELECTION())
%QUOTE%

%ELEMSUFFIX

%ELEMSUFFIX( 


pathnames )                                macro 

Append extended naming symbol (@@) to pathnames (see Table 18-11 and Example 18-11.)

Table 18-15. %ELEMSUFFIX Modifier Macro

Argument

Values

pathnames

Any pathname(s) (non-element pathnames are returned unchanges)


Example 18-11. ELEMSUFFIX


f.exec %QUOTE%
cleartool lsvtree %ELEMSUFFIX(
%ELEMENT(
%PNAME(Element whose version tree is to be listed,
INVOB ELEM)))
%QUOTE%

%MOUNT

%MOUNT( 


pathnames )                                     macro 

Return the VOB mount points (VOB-tags) of specified pathnames (see Table 18-11 and Example 18-12.)

Table 18-16. %MOUNT Modifier Macro

Argument

Values

pathnames

Any pathname(s) within one or more VOBs


Example 18-12. MOUNT


f.exec %QUOTE
%TEXTOUT(Mount List,"No mounted VOBs specified",6,4)
echo '%MOUNT(%PNAME[](Select VOB pathname%(s%),INVOB))'
%QUOTE%

The two parenthesis characters are escaped — %( and %) — to protect them from the macro expansion pass.

%RELATIVE

%RELATIVE( 


pathnames,


dir )                              macro 

Convert full or relative pathnames into pathnames relative to directory (see Table 18-11 and Example 18-13.)

Table 18-17. %RELATIVE Modifier Macro

Argument

Values

pathnames

Any pathname(s) within one or more VOBs

dir

The directory to which the converted pathnames are to be relative


Example 18-13. RELATIVE


f.exec %QUOTE%
#!/bin/sh
PATH=$PATH:$HOME/%RELATIVE(
%PNAME(Select a dir anywhere under your home dir),$HOME)
%QUOTE%

%SETVIEW

%SETVIEW( 


pathnames )                                   macro 

Convert pathnames to view-extended pathnames, based on the current set view (see Table 18-11 and Example 18-14.)

Table 18-18. %SETVIEW Modifier Macro

Argument

Values

pathnames

Any pathname(s)

The example invokes a text editor on the selected file.

Example 18-14. SETVIEW


f.exec %QUOTE%
%WHICH(GRP_PATH,editor.sh) %SETVIEW(%SELECTION())
%QUOTE%


Note: If the argument is already a view-extended pathname, it is unchanged by %setview, regardless of the view-tag on which it is based.


%SORT

%SORT( 


pathnames )                                      macro

Sort pathnames as shown in Table 18-11 and Example 18-15.

Table 18-19. %SORT Modifier Macro

Argument

Values

pathnames

Any pathname(s)


Example 18-15. SORT


f.exec %QUOTE%
echo '%SORT(%PNAME[]())' %TEXTOUT(Sorted Pnames,,8,4)
%QUOTE%
%VERMOD( 


pathnames )                                    macro 

Convert standard pathnames to version-extended pathnames (see Table 18-11 and Example 18-16.)

Table 18-20. %VERMOD Modifier Macro

Argument

Values

pathnames

Any pathname(s) (non-element pathnames are returned unchanges)


Example 18-16. VERMOD


f.exec %QUOTE%
cleartool findmerge %SELECTION() -xmerge -log /dev/null \
  -whynot -fver %VERMOD(  %PNAME(
Select 'from' version: ['to' %VERMOD(%SELECTION())],ELEM INVOB,
vtree %SELECTION())
) | grep -v "Needs Merge"  %TEXTOUT("Merge Info",,8,2)
%QUOTE%

%WHICH

%WHICH( 


path-ev,


filename )                              macro 

Search specified path for the first occurrence of filename (see Table 18-11 and Example 18-17.)

Table 18-21. %WHICH Modifier Macro

Argument

Values

path-EV

Any environment variable that stores a directory search path (typically, grp_path)

filename

Any valid file name (a shell script or executable)


Example 18-17. WHICH


f.exec %QUOTE%
%WHICH(GRP_PATH,editor.sh) %SETVIEW(%SELECTION())
%QUOTE%

Like the unix which(1) command, %which returns (by searching path-EV) the full pathname of its filename argument. The %which macro exists to help support local customizations to the ClearCase-supplied .sh scripts that are installed in /usr/atria/config/ui/grp.

The ClearCase-supplied group files include a number of f.exec scripts that invoke .sh files to perform specialized processing — finding and invoking the user's preferred text editor, for example. To customize a .sh file, first copy it to another directory. Make sure this directory occurs in the path-EV, and use %which to invoke your customized file.

For example, suppose you copy the file term_display.sh to $home/.grp and customize it. If your grp_path variable is set to $home/.grp:/usr/atria/config/ui/grp (which is the default), then the macro %WHICH(GRP_PATH,term_display.sh) finds and executes your version.

%WILD

%WILD( 


pathnames )                                      macro 

Expand wildcards in pathnames (see Table 18-11 and Example 18-18.)

Table 18-22. %WILD Modifier Macro

Argument

Values

path-expr

Pathname with one or more of these wildcard characters:
(“), “*”, or “?”


Example 18-18. WILD


f.exec %QUOTE%
%PNAME(%WILD(%STRING()))
%QUOTE%

Output Macros

By default, the output generated by menu commands is collected in the transcript pad. The %listout and %textout macros redirect standard output to a list browser or read-only text window, respectively.

Both %textout and %listout redirect output for the entire f.exec operation, regardless of their location in the script. Either macro “expands” to the null string in the script; output redirection is established during the macro expansion “pre-pass”.

%LISTOUT

%LISTOUT( 


title,


class,


persistence,


width,


height )        macro 

Redirect output to a list browser (named or unnamed) (see Table 18-11 and Example 18-19.)

Table 18-23. %LISTOUT Output Macro

Argument

Values

Default

title

Character string

Enter string

class

Character string

class of active browser when macro invoked

persistence

TRANSIENT

browser stays up until user closes it

width

1-32 (window width in inches)

8

height

1-32 (window height in inches)

4


Example 18-19. LISTOUT


f.exec %QUOTE%
cleartool lsch -short . %LISTOUT(VOB Checkouts,,,6,4)
%QUOTE%

Use %listout to capture lists of pathnames or other VOB objects into a named list browser, from which data can later be selected (see %list) and supplied to other operations.

The title argument gives the list browser a name, which %list then uses to refer to the browser when using it to collect user input.

The optional class argument specifies a list browser class. You can scope a group file to a list browser class (giving the class an arbitrary name: Scope myList:toolbar, for example), thereby providing a set of menu items for the user to choose from when such a list browser is displayed. The group file menu appears on any list browser that %listout creates with the applicable class argument.

List data entries are separated or terminated by <nl> or null characters. Furthermore, within a single list entry (one line), only the text before the first tab character is returned by %list; the rest is ignored.

By default, a list browser created with %listout stays up until the user closes it. The TRANSIENT argument forces the list browser to close after either:

  • a %list macro generates a prompt in that list browser, and the user responds to the prompt by pressing Ok or Cancel, or

  • the menu item's command operation completes.

%TEXTOUT

%TEXTOUT( 


title,


default-text,


width,


height )             macro 

Redirect standard output to read-only text-display window (see Table 18-11 and Example 18-20.)

Table 18-24. %TEXTOUT Output Macro

Argument

Values

Default

title

Title of text browser

default-text

Character string

 

width

1-32 (window width in inches)

8

height

1-32 (window height in inches)

4


Example 18-20. TEXTOUT


f.exec %QUOTE%
%TEXTOUT("Describe",,8,2)
cleartool lstype -attype -long %SELECTION() 2>&1"
%QUOTE%

Unlike %listout, %textout redirects the standard output of commands to an untyped, read-only text window. Use %textout when your only objective is to display information.

The default text argument (def-text) specifies text to be displayed if the redirected operations generate no output.

Like %listout, %textout redirects stdout for the entire f.exec script. To redirect both stderr and stdout for a given command, use the /bin/sh construct 2>&1.

Text Output and Terminal Emulation Windows

For comparison with list browsers, Figure 18-15 shows a sample text output window, and Figure 18-16 shows a terminal emulation window. Neither prompts for, or accepts, user input; they are display-only devices.

Figure 18-15. A Text Output Window


Figure 18-16. A Terminal Emulation Window


The text output window was generated by the Describe button and the terminal window by menu item Report -> Find query -> Whole VOB -> Versions with Label...

You can cancel output to a terminal emulation window with <Ctrl-C>.

Memory Macros

Use the %save and %restore macros to mimic user-defined shell variables inside other xclearcase macros. Because xclearcase simply expands macros into strings (before running the execution script), you cannot use shell variables or other shell constructs inside macros. However, in an f.exec script, you can use %save to store and name an arbitrary string. Later in the same script — or in a subsequent f.exec script — you can use %restore to apply the saved string in a command line (including inside an xclearcase macro).

By default, the temporary storage is release when the f.exec script terminates. Use the KEEP argument to retain the temporary variable until either (a) it is released by a %remove macro, or (b) the xclearcase session terminates.

%SAVE

%SAVE( 


var-name,


string,


persistence )                    macro 

Save string into named temporary variable (can be referenced with %RESTORE (see Table 18-11 and Example 18-21.))

Table 18-25. %SAVE Memory Macro

Argument

Values

Default

var-name

Name of temporary variable

Enter string

string

Character string to be stored in variables

 

persistence

KEEP

variable removed after this f.exec completes


Example 18-21. SAVE


f.exec %QUOTE%
%SAVE(dir, %PNAME(Select target dir, DIR INVOB),KEEP)
  .
  .
DIR='%RESTORE(dir)' %REMOVE(dir)
%QUOTE%

%REMOVE

%REMOVE( 


var-name )                                     macro 

Delete a persistent temporary variable created with %SAVE (see Table 18-11 and Example 18-22.)

Table 18-26. %REMOVE Memory Macro

Argument

Values

var-name

Name of temporary variable


Example 18-22. REMOVE


f.exec %QUOTE%
%SAVE(tmp_print_file, %TMPFILE(), KEEP)
  .
  .
%REMOVE(tmp_print_file)
%QUOTE%

%RESTORE

%RESTORE( 


var-name )                                    macro 

Retrieve the value of a temporary variable created with %SAVE (see Table 18-11 and Example 18-23.)

Table 18-27. %RESTORE Memory Macro

Argument

Values

var-name

Name of temporary variable


Example 18-23. RESTORE


f.exec %QUOTE%
%SAVE(dir, %PNAME(Select target directory, DIR INVOB))
  .
  .
DIR='%RESTORE(dir)'
%QUOTE%

Miscellaneous Macros

These macros take no arguments.

%SELECTION

%SELECTION( )                                           macro 

Return the current data selection(s) from the current browser (see Example 18-24.)

Example 18-24. SELECTION


f.exec %QUOTE%
cleartool uncheckout -rm %SELECTION()
%QUOTE%

The %selection() macro is replaced by the data that has been preselected by the user. %selection() can appear only in items in which the f.exec strings is preceded by an activation clause.

%DIR

%DIR( )                                                 macro 

Return the pathname of the current browser's directory (see Example 18-25.)

Example 18-25. DIR


f.exec %QUOTE%
echo "Current working dir is %DIR()"
%QUOTE%

%NAME

%NAME( )	macro

Return the name associated with the current browser (see Example 18-26.)

Example 18-26. NAME


f.exec %QUOTE%
%WHICH(GRP_PATH,term_display.sh) USE_MORE \
cleartool lshistory -long %NAME()
%QUOTE%"

For a vtree browser, expands to name of the element whose vtree is displayed. For all other browsers, expands to the current directory pathname.

%TMPFILE

%TMPFILE( )                                             macro 

Create a temporary file and return its pathname (see Example 18-27.)

Example 18-27. TMPFILE


f.exec %QUOTE%
%SAVE(tmp_print_file, %TMPFILE(), KEEP)
%QUOTE%

This example creates a temporary file in $TMPDIR (or /usr/tmp, if this EV is not set). The full pathname of the temporary file is placed in the xclearcase variable tmp_print_file.

Customization Procedures

Customization tasks fall into two general categories:

  • add a new menu

  • replace an existing menu

Here are the basic procedures for accomplishing each task.

Adding a New Menu

  1. Copy to your work area (typically, $home/.grp) the predefined group file template /usr/atria/config/ui/grp/user.grp.template, which is a syntax skeleton. Rename the file to user.grp, or to some other name with a .grp suffix.

  2. Determine a scope for your new menu (Fast:pulldown, Vtree:pulldown, or File:pulldown, for example).

    The template group file defaults to Fast:pulldown scope. This positions the new menu on the file browser's Fast pulldown menu and, optionally, as a set of buttons on the file browser toolbar. See “Scope” for more details.

  3. Replace the template group file's menu item definitions with your own. Copy and modify an item definition from one of the ClearCase-supplied group files (ideally, one that does some or all of the desired operation).

    Each item definition must include at least a label (or no-label) and an f-dot function. (Most will include one or more f.exec scripts.) For a pull-down or pop-up menu item, it is good practice to add a menu mnemonic and, when applicable, a preselect clause. For a toolbar button, you may wish to add bitmap icons. If your menu will be used by others, supply f.help strings for all menu items.

    Before attaching a complex script to a menu item, see “Complex Execution Scripts”, below.

  4. Restart xclearcase and test the new menu items.

    Because the group files are read once at startup time and cached, you must exit and restart xclearcase to activate any group file changes. In general, a menu is ignored (it does not appear in the interface) if its group file contains syntax errors; check the transcript pad for diagnostic messages.

    By default, /bin/sh is used to execute your f.exec scripts. Include a first line like #!/bin/csh to specify another shell.


    Note: If you set the environment variable clearcase_dbg_grp to a non-zero value, xclearcase sends debugging information to the transcript pad when executing commands.


Replacing an Existing Menu

  1. Find the ClearCase-supplied .grp file you want to customize (typically, to add new items) and copy it to $home/.grp, or to any directory in your grp_path that precedes /usr/atria/config/ui/grp. Because xclearcase ignores any group file with the same name as one already scanned in, your copied group file now “eclipses” the standard group file.

  2. Add your own item definitions.


    Note: Although you are now in a position to modify the predefined menu items, this is not advised. Such customizations are equivalent to modifying the source code, and have the potential to leave you “out of sync” with future ClearCase-supplied enhancements and bug fixes to the standard group files.


  3. Restart xclearcase and test each new menu item.

Complex Execution Scripts

The technique described here is recommended if you are attaching either of the following to a menu item:

  • a complex operation

  • an operation that must be repeated for multiple menu items

Code the “meat” of the operation as a standard shell script (no ClearCase macros), and invoke the script from an f.exec script using the %which macro. The %which macro is described on page 275. The ClearCase-supplied group files include numerous examples of this technique (calling the various .sh scripts installed in /usr/atria/config/ui/grp).

For example, the following item definition includes an f.exec script that calls print_file.sh to find a print command and then print the preselected files:

"Print" _P %PNAME[](NDIR) & \
f.exec %QUOTE%
       %WHICH(GRP_PATH,print_file.sh) %SETVIEW(%SELECTION())
       %QUOTE% \
f.help "Print the selected files."


Note: “external” scripts cannot use xclearcase macros to collect input and, therefore, must use clearprompt or some other mechanism to do so.


Resource Schemes

ClearCase provides a number of predefined color and font combinations for use with the graphical interface. Each predefined collection of resources is called a scheme. See the schemes manual page for details.


Note: The scheme files commonly set specific widget class resources. Therefore, xclearcase command line options (for example, -bg and -fg) may not work as expected, because they set resources at the most general level. You have the option to disable schemes, to modify them, or to set still more specific resources.


Icon Display in the File Browser

A file browser can display file system objects either by-name or graphically. In the latter case xclearcase selects an icon for each file system object as follows:

  • In a process described in the cc.magic manual page, xclearcase uses an object's name, and/or its contents, to compile a list of one or more file types that correspond to the object.

  • One by one, the file types are compared to the rules in predefined and user-defined icon files, as described in the cc.icon manual page. For example, the file type c_source matches this icon file rule:

    c_source : -icon c ;
    

As soon as a match is found, the search ends. The token following -icon identifies the icon's bitmap file.

  • By default, xclearcase searches first for the bitmap file (which must be in bitmap(1) format) in the .bitmaps subdirectory of your home directory, then in /usr/atria/config/ui/bitmaps. If the bitmap_path variable is set, xclearcase searches the directories there instead.

  • If a valid bitmap file is found, xclearcase displays it; otherwise, the search for an icon continues with the next file type.

The name of an icon file should include a numeric suffix, which need not be specified in the icon file rule. The suffix tells xclearcase how much screen space to allocate for the icon. Each bitmap supplied with ClearCase is stored in a file with a .60 suffix (for example, lib.60), indicating a 60x60 icon.

Enabling a Customized Icon

The following steps install a customized icon for unix-style manual page source files.

  1. Add a rule to your personal magic file ($home/.magic) that includes manpage among the file types assigned to all manual page source files:

        manpage src_file text_file file:  -name "*.[1-9]" ;
    

  2. Add a rule to your personal icon file (in directory $home/.icon) that maps manpage to a user-defined bitmap file:

        manpage : -icon manual_page_icon ; manpage : -icon manual_page_icon ;
    

  3. Create a manpage icon in your personal bitmaps directory ($home/.bitmaps) by revising one of the standard icon bitmaps with the X bitmap utility:

    % mkdir $HOME/.bitmaps
    % cd $HOME/.bitmaps
    % cp /usr/atria/config/ui/bitmaps/c.60 manual_page_icon.60
    % bitmap manual_page_icon.60
    

  4. Test your work by having an xclearcase file browser display a manual page source file (Figure 18-17).

    Figure 18-17. User-Defined Icon Display