<!-- $XConsortium: WML.sgm /main/10 1996/09/08 21:23:22 rws $ -->
<!-- (c) Copyright 1995 Digital Equipment Corporation. -->
<!-- (c) Copyright 1995 Hewlett-Packard Company. -->
<!-- (c) Copyright 1995 International Business Machines Corp. -->
<!-- (c) Copyright 1995 Sun Microsystems, Inc. -->
<!-- (c) Copyright 1995 Novell, Inc. -->
<!-- (c) Copyright 1995 FUJITSU LIMITED. -->
<!-- (c) Copyright 1995 Hitachi. -->

<RefEntry Id="CDEMMA.MAN574.rsml.1">
<RefMeta>
<RefEntryTitle>WML</RefEntryTitle>
<ManVolNum>file formats</ManVolNum>
</RefMeta>
<RefNameDiv>
<RefName><Symbol Role="Define">WML</Symbol></RefName>
<RefPurpose>The widget meta-language file format for creating uil compilers
<IndexTerm>
<Primary>widget meta-language</Primary>
</IndexTerm></RefPurpose>
</RefNameDiv>
<!-- -->
<!-- @OSF_COPYRIGHT@-->
<!-- COPYRIGHT NOTICE-->
<!-- Copyright (c) 1990, 1991, 1992, 1993 Open Software Foundation, Inc.-->
<!-- ALL RIGHTS RESERVED (MOTIF). See the file named COPY.MOTIF.DOC for-->
<!-- the full copyright text.-->
<!-- -->
<!-- HISTORY-->
<!-- -->
<!-- **-->
<!-- **-->
<!-- **  (c) Copyright 1991, 1992 by Open Software Foundation, Inc.-->
<!-- **      All Rights Reserved.-->
<!-- **-->
<!-- **  (c) Copyright 1987, 1988 by Digital Equipment Corporation,-->
<!-- **      Maynard, MA.  All Rights Reserved.-->
<!-- **-->
<!-- **-->
<IndexTerm>
<Primary>WML</Primary>
</IndexTerm>
<RefSect1>
<Title>DESCRIPTION</Title>
<Para>The widget meta-language facility (WML) is used to generate the
components of the user interface language (UIL) compiler that
can change depending on the widget set. Using WML you can add support
in UIL for
new widgets to the Motif widget set or for a totally new widget set.
</Para>
<RefSect2>
<Title>File</Title>
<Para>WML files are ASCII files that you can modify with any standard
text editor. They are accessed in the
<Literal>tools/wml</Literal> directory by WML.
By convention WML files have the suffix <Literal>&npzwc;.wml</Literal>.
The Motif widget set is described in the
<Literal>motif.wml</Literal> file.
This is also the default WML file when using the WML facility.
</Para>
<Para>When adding new widgets or changing widget characteristics, you should
start with a copy of the
<Literal>motif.wml</Literal> file.
If you are creating a new widget set for use with UIL, you should
start from scratch.
In either case the
<Literal>motif.wml</Literal>
file is a good example of WML syntax, and you should familiarize
yourself with it before writing your own WML file.
</Para>
<Para>WML files have a simple syntax, similar in structure to UIL.
It is made up of the following elements:
</Para>
<ItemizedList>
<ListItem>
<Para>Comments
</Para>
</ListItem>
<ListItem>
<Para>Data Type Definitions
</Para>
</ListItem>
<ListItem>
<Para>Character Set Definitions
</Para>
</ListItem>
<ListItem>
<Para>Enumeration Set Definitions
</Para>
</ListItem>
<ListItem>
<Para>Control List Definitions
</Para>
</ListItem>
<ListItem>
<Para>Class Definitions
</Para>
</ListItem>
<ListItem>
<Para>Child Definitions
</Para>
</ListItem>
<ListItem>
<Para>Resource Definitions
</Para>
</ListItem>
</ItemizedList>
<Para>You can use space, tabs, or newlines anywhere in the syntax,
as long as you do not split up keywords or strings, except that
comments end at a newline.
The order of elements is not important to the syntax.
</Para>
<Para>This description uses the following additional conventions
to describe the syntax of the widget meta-language:
</Para>
<VariableList>
<VarListEntry>
<Term>[&ensp;&ensp;]</Term>
<ListItem>
<Para>Indicates optional elements.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>...</Term>
<ListItem>
<Para>Indicates where an element of syntax can be repeated.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>|</Term>
<ListItem>
<Para>Indicates a choice among multiple items.
</Para>
</ListItem>
</VarListEntry>
</VariableList>
</RefSect2>
<RefSect2>
<Title>Comments</Title>
<Para>You can include comments in the WML file.
Comments have the following syntax:
</Para>
<Synopsis>[any.element]!any.comment
</Synopsis>
<Para>Comments begin with an exclamation point and extend to the
end of the line. A comment can begin on a line by itself or
follow any part of another element. A comment does not change
the meaning of any other element.
For example:
</Para>
<InformalExample>
<ProgramListing>!This is a comment
!  that spans two lines.
DataType    !This is a comment following code.
</ProgramListing>
</InformalExample>
</RefSect2>
<RefSect2>
<Title>Data Type Definitions</Title>
<Para>Data type definitions register all the resource data
types used in the file. You must register all the data types used
in your WML file.
Data type definitions have the following syntax:
</Para>
<Synopsis>DataType
     any.datatype [{ InternalLiteral = internal.name |
          DocName = "<Symbol Role="Variable">string</Symbol>"; [...]}];
     [...]
</Synopsis>
<Para>A data type definition begins with the keyword <Literal>DataType</Literal>. Following
the
<Literal>DataType</Literal> keyword is a list of data types that can be further modified with
</Para>
<VariableList>
<VarListEntry>
<Term><Literal>InternalLiteral</Literal></Term>
<ListItem>
<Para>This forces the value of the internal symbol table literal definition
of the data type name. This modifier is only used to get around
symbol table definitions hard coded into the UIL compiler.
It should rarely be used.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term><Literal>DocName</Literal></Term>
<ListItem>
<Para>This gives an arbitrary string for use in the documentation.
This string is meant to supply a different name for the data type for
use in the documentation, or a single name for the data type if the
data type has aliases.
</Para>
</ListItem>
</VarListEntry>
</VariableList>
<Para>For example:
</Para>
<InformalExample>
<ProgramListing>DataType OddNumber {DocName="OddNumber";};
         NewString;
</ProgramListing>
</InformalExample>
</RefSect2>
<RefSect2>
<Title>Character Set Definitions</Title>
<Para>Character set definitions register the Motif Toolkit name and other
information for the character set names used in UIL.
Character set definitions have the following syntax:
</Para>
<Synopsis>CharacterSet
     any.character.set
          { [ FontListElementTag | XmStringCharsetName ] = "<Symbol Role="Variable">string</Symbol>";
               [ Alias = "<Symbol Role="Variable">string</Symbol>" ...; |
               Direction = [ LeftToRight | RightToLeft ]; |
               ParseDirection = [ LeftToRight | RightToLeft ]; |
               CharacterSize = [ OneByte | TwoByte ]; ]
               [ ... ] };
     [ ... ]
</Synopsis>
<Para>A character set definition begins with the keyword <Literal>CharacterSet</Literal>.
Following the <Literal>CharacterSet</Literal> keyword is a list of character sets
that can be further modified with
</Para>
<VariableList>
<VarListEntry>
<Term><Literal>FontListElementTag</Literal>&ensp;|&ensp;<Symbol>XmStringCharsetName</Symbol></Term>
<ListItem>
<Para>Specifies the name of the character set, which will become the character
set component of a compound string segment created using this
character set.
This modifier is required.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term><Literal>Alias</Literal></Term>
<ListItem>
<Para>Specifies one or more aliases for the character set name.
Each alias can be used within UIL to refer to the same character set.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term><Literal>Direction</Literal></Term>
<ListItem>
<Para>Specifies the direction of a compound string segment created using
this character set.
The default is <Literal>LeftToRight</Literal>.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term><Literal>ParseDirection</Literal></Term>
<ListItem>
<Para>Specifies the direction in which an input string is parsed when a
compound string segment is created using this character set.
The default is whatever <Literal>Direction</Literal> is specified.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term><Literal>CharacterSize</Literal></Term>
<ListItem>
<Para>Specifies the number of bytes in each character of a compound string
segment created using this character set.
The default is <Literal>OneByte</Literal>.
</Para>
</ListItem>
</VarListEntry>
</VariableList>
<Para>For example:
</Para>
<InformalExample>
<ProgramListing>CharacterSet
  iso_latin1
    { XmStringCharsetName = "ISO8859-1";
      Alias = "ISOLatin1"; };
  iso_hebrew_lr
    { XmStringCharsetName = "ISO8859-8";
      Alias = "iso_latin8_lr";
      Direction = RightToLeft;
      ParseDirection = LeftToRight; };
  ksc_korean
    { XmStringCharsetName = "KSC5601.1987-0";
      CharacterSize = TwoByte; };
</ProgramListing>
</InformalExample>
</RefSect2>
<RefSect2>
<Title>Enumeration Set Definitions</Title>
<Para>Enumeration set definitions register the named constants used in the
Motif Toolkit to specify some resource values.
Enumeration set definitions have the following syntax:
</Para>
<Synopsis>EnumerationSet
     resource.name: resource.type
          { enum.value.name; [ ... ] };
</Synopsis>
<Para>An enumeration set definition begins with the keyword
<Literal>EnumerationSet</Literal>.
For each enumeration set defined, the name and type of the resource are
listed.
The resource name is the Motif Toolkit resource name, with the beginning
<SystemItem Class="Constant">XmN</SystemItem> removed and with the initial letter capitalized.
For example, the name of the Motif Toolkit resource
<SystemItem Class="Resource">XmNrowColumnType</SystemItem> is <Literal>RowColumnType</Literal>.
The resource type is the data type for the resource; for most resources,
this is <Symbol Role="Variable">integer</Symbol>.
Following the resource name and type is a list of names of enumeration
values that can be used as settings for the resource.
These names are the same as those in the Motif Toolkit.
</Para>
<Para>For example:
</Para>
<InformalExample>
<ProgramListing>EnumerationSet
  RowColumnType: integer
    { XmWORK_AREA; XmMENU_BAR; XmMENU_POPUP;
      XmMENU_PULLDOWN; XmMENU_OPTION; };
</ProgramListing>
</InformalExample>
<Para>Enumeration sets also support Boolean values.
</Para>
</RefSect2>
<RefSect2>
<Title>Control List Definitions</Title>
<Para>Control list definitions assign a name to groups of controls.
You can use these control lists later in class definitions to simplify
the structure of your WML file.
Control list definitions have the following syntax:
</Para>
<Synopsis>ControlList
     any.control.list [{ any.control; [...]}];
</Synopsis>
<Para>A control list definition starts with the
<Literal>ControlList</Literal> keyword.
Following the
<Literal>ControlList</Literal> keyword are any number of control list definitions. Control list
definitions are made up of a control list name followed by the
set of controls it represents. For example:
</Para>
<InformalExample>
<ProgramListing>ControlList
        Buttons {PushButton;
                 RadioButton;
                 CascadeButton;
                 NewCascadebutton;};
</ProgramListing>
</InformalExample>
<Para>Each control specified in the control list must be defined as
a class in the file.
</Para>
</RefSect2>
<RefSect2>
<Title>Class Definitions</Title>
<Para>Class definitions describe a particular widget class including
its position in the class hierarchy, toolkit convenience function,
resources, and controls. There should be one class definition for
each widget or gadget in the widget set you want to support in UIL.
Class definitions have the following syntax:
</Para>
<Synopsis>Class class.name: MetaClass | Widget | Gadget
     [{[
     SuperClass = class.name; |
     ParentClass = parent.class.name; |
     InternalLiteral = internal.name; |
     Alias = <Symbol Role="Variable">alias</Symbol>; |
     ConvenienceFunction = convenience.function; |
     WidgetClass = widget.class; |
     DocName = "<Symbol Role="Variable">string</Symbol>"; |
     DialogClass = True | False; |
     Resources { any.resource.name [{
               Default = new.default.value; |
               Exclude = True |
               False;
               [...]} ];
          [...]}; |
     Controls { any.control.name; [...]};
     Children { any.child.name; [...] };
     [...]
     ]}];
</Synopsis>
<Para>Class definitions start with the
<Literal>Class</Literal> keyword.
For each class defined, the name of the class and whether the
class is a metaclass, widget, or gadget is listed.
Each class definition can be further modified with the
keywords described in the following list.
</Para>
<VariableList>
<VarListEntry>
<Term><Literal>SuperClass</Literal></Term>
<ListItem>
<Para>This indicates the name of the parent class.
Only the root of the hierarchy does not specify a SuperClass.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term><Literal>ParentClass</Literal></Term>
<ListItem>
<Para>This indicates the name of the widget's automatically created
parent class if one exists. This allows resources for that
automatically created class to be used in instances of this class.
For example, <Symbol>XmBulletinBoardDialog</Symbol> creates both an
<Classname>XmBulletinBoard</Classname> and an <Classname>XmDialogShell</Classname>. To access the
resources of the <Classname>XmDialogShell</Classname> parent class it must be
specified here.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term><Literal>InternalLiteral</Literal></Term>
<ListItem>
<Para>This forces the value of the internal symbol table literal definition
of the class name. This modifier is only used to get around
symbol table definitions hard coded into the UIL compiler.
It should rarely be used.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term><Literal>Alias</Literal></Term>
<ListItem>
<Para>This indicates alternate names for the class
for use in a UIL specification.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term><Literal>ConvenienceFunction</Literal></Term>
<ListItem>
<Para>This indicates the name of the creation convenience function
for this class. All widget and gadget classes must have a
<Literal>ConvenienceFunction.</Literal></Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term><Literal>WidgetClass</Literal></Term>
<ListItem>
<Para>This indicates the associated widget class of gadget type classes.
Presently, nothing is done with this value.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term><Literal>DocName</Literal></Term>
<ListItem>
<Para>This defines an arbitrary string for use in the documentation.
Presently, nothing is done with this value.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term><Literal>DialogClass</Literal></Term>
<ListItem>
<Para>This indicates whether the class is a dialog class.
Presently, nothing is done with this value.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term><Literal>Resources</Literal></Term>
<ListItem>
<Para>This lists the resources of the widget class. This keyword
can be further modified with
</Para>
<VariableList>
<VarListEntry>
<Term><Literal>Default</Literal></Term>
<ListItem>
<Para>This specifies a new default value for this resource. Resource
default values are usually set in the resource definition. If
an inherited resource's default value is changed by the class,
the new default value should be noted here.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term><Literal>Exclude</Literal></Term>
<ListItem>
<Para>This specifies whether an inherited resource should be excluded from the
resource list of the class. <Literal>Exclude</Literal> is False by default.
</Para>
</ListItem>
</VarListEntry>
</VariableList>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term><Literal>Children</Literal></Term>
<ListItem>
<Para>This lists the names of the automatically created children of this
class, so that those children can be accessed in the UIL file.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term><Literal>Controls</Literal></Term>
<ListItem>
<Para>This lists the controls that the widget class allows. The controls can
be other classes or a control list from the control list definition.
</Para>
</ListItem>
</VarListEntry>
</VariableList>
<Para>The following example uses the examples from the data type definitions and
control list definitions above.
</Para>
<InformalExample>
<ProgramListing>Class
     TopLevelWidget: MetaClass
          {
          Resources
               {
               XtbNfirstResource;
               XtbNsecondResource;
               };
          };
     NewWidget: Widget
          {
          SuperClass = TopLevelWidget;
          ConvenienceFunction =
              XtbCreateNewWidget;
          Resources
               {
               XtbNnewResource;
               XtbNfirstResource
                  {Default="XtbNEW_VALUE";};
               XtbNsecondResource
                  {Exclude=True;};
               };
          Controls
               {
               NewWidget;
               Buttons;
               };
          };
</ProgramListing>
</InformalExample>
</RefSect2>
<RefSect2>
<Title>Child Definitions</Title>
<Para>Child definitions register the classes of automatically created
children. Automatically created children are referenced elsewhere in
a <Command>uil</Command> file using the <Literal>Children</Literal> keyword within a class definition.
Child definitions have the following syntax:
</Para>
<Para><Literal>Child</Literal>
<StructField>child.name</StructField> <Literal>:</Literal> <StructField>class.name</StructField><Literal>;</Literal>
[...]
</Para>
<Para>Where <StructField>child.name</StructField> is the name of the automatically created child
and <StructField>class.name</StructField> is the name of the class of that child.
</Para>
</RefSect2>
<RefSect2>
<Title>Resource Definitions</Title>
<Para>Resource definitions describe a particular resource including
its type, and default value.
There should be a resource definition for
each new resource referenced in the class definitions.
Resource definitions have the following syntax:
</Para>
<Synopsis>Resource
     resource.name: Argument | Reason | Constraint | SubResource
          [{[
          Type = <Symbol Role="Variable">type</Symbol>;
          [ResourceLiteral = resource.literal; ]
          [InternalLiteral = internal.name; ]
          [Alias = <Symbol Role="Variable">alias</Symbol>; ]
          [Related = <Symbol Role="Variable">related</Symbol>; ]
          [Default = <Symbol Role="Variable">default</Symbol>; ]
          [DocName = doc.name; ]
          [...]}]
     [...]
</Synopsis>
<Para>Resource definitions start with the
<Literal>Resource</Literal> keyword.
For each resource definition,
the name of the resource and whether the resource is an argument, reason,
constraint or subresource is listed.
</Para>
<VariableList>
<VarListEntry>
<Term><Literal>Argument</Literal></Term>
<ListItem>
<Para>Indicates a standard resource
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term><Literal>Reason</Literal></Term>
<ListItem>
<Para>Indicates a callback resource
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term><Classname>Constraint</Classname></Term>
<ListItem>
<Para>Indicates a constraint resource
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term><Literal>SubResource</Literal></Term>
<ListItem>
<Para>Presently, nothing is done with this value
</Para>
</ListItem>
</VarListEntry>
</VariableList>
<Para>The resource definition can be further modified with the following
keywords:
</Para>
<VariableList>
<VarListEntry>
<Term><Literal>Type</Literal></Term>
<ListItem>
<Para>This indicates the data type of the resource. It must be listed
in the data type definition.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term><Literal>ResourceLiteral</Literal></Term>
<ListItem>
<Para>This indicates the keyword used in the UIL file to reference the
resource. In Motif, the resource name is the same as the
<Literal>ResourceLiteral</Literal>.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term><Literal>InternalLiteral</Literal></Term>
<ListItem>
<Para>This forces the value of the internal symbol table literal definition
of the resource name. This modifier is only used to get around
symbol table definitions hard coded into the UIL compiler.
It should rarely be used.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term><Literal>Alias</Literal></Term>
<ListItem>
<Para>This indicates alternate names for the resource
for use in a UIL specification.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term><Literal>Related</Literal></Term>
<ListItem>
<Para>This is a special purpose field that allows resources that
act as a counter for the current resources to be related to the resource.
UIL automatically sets the value of this related resource to the number of items
in the compiled instance of type <StructField>resource.name</StructField>.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term><Literal>Default</Literal></Term>
<ListItem>
<Para>This indicates the default value of the resource.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term><Literal>DocName</Literal></Term>
<ListItem>
<Para>This defines an arbitrary string for use in the documentation.
Presently, nothing is done with this value.
</Para>
</ListItem>
</VarListEntry>
</VariableList>
<Para>The following example uses the examples from the data type definitions,
control list definitions and class definitions above.
</Para>
<InformalExample>
<ProgramListing>Resource
     XtbNfirstResource: Argument
          { Type = OddNumber;
            Default = "XtbOLD_VALUE";};
     XtbNsecondResource: Argument
          { Type = NewString;
            Default = "XtbNEW_STRING"; };
     XtbNnewResource: Argument
          { Type = OddNumber;
            Default = "XtbODD_NUMBER"; };
</ProgramListing>
</InformalExample>
</RefSect2>
</RefSect1>
</RefEntry>
<!--fickle 1.09 7/2/95-->
