Geometries are vector-based descriptions and composite groupings that allow you to define a subset of the visual attributes of your repository elements. These particular attributes define the geometric shapes that are rendered whenever a visual element is drawn in a repository or document view.

The following xml fragment is part of the file named geometry.xml. Here you should quickly glance over its contents and ponder the composite geometry named “AppLabelGeometryDescriptor”. A composite geometry, referred to as a GeometryDescriptor, combines one or more individually-defined GeometryItem elements previously declared in the same geometry.xml file.

In this and the following sections, we will generally describe the most important structural aspects of all of these xml elements and point you to additional resources that thoroughly discuss the configuration possibilities available to you.

...

<list name="GeometryItem">
  <attribute name="Name" value="AppTitleLabel"/>
  <attribute name="Type" value="Label"/>
  <set name="Attributes">
    <attribute name="Text" value="Application"/>
    <attribute name="FontUnit" value="Point" />
    <attribute name="HorizontalAlignment" value="Center" />
    <attribute name="VerticalAlignment" value="Center" />
    <attribute name="SizeAdjustment" value="LineCountAndLength"/>
    <attribute name="Clipping" type="Boolean" value="true"/>
    <attribute name="LineShortening" type="Boolean" value="false"/>
    <attribute name="WordWrap" type="Boolean" value="false"/>
    <attribute name="FirstWordCharacterWrap" type="Boolean" value="false"/> 
    <attribute name="Editable" type="Boolean" value="false"/>       
  </set>
</list> 

...

<list name="GeometryDescriptor">
  <attribute name="Name" value="AppLabelGeometryDescriptor" />
  <attribute name="Type" value="Composite" />
  <list name="CoordinateSystem">
    <attribute name="ScaleX" value="0mm, 10mm"/>
    <attribute name="ScaleY" value="0mm, 10mm"/>
  </list>
  <set name="Attributes">
      <attribute name="MinimumSize" type="Size" value="10mm, 10mm" />
  </set>
  <list name="DescriptorItems">    
    <list name="DescriptorItem">
      <attribute name="Name" value="TitleArea" />
      <attribute name="GeometryItemName" value="AppTitleLabel" />
      <list name="Coordinates">
        <attribute name="Coordinate" value="0.0mm, 0.0mm" />
        <attribute name="Coordinate" value="10.0mm, 3.0mm" />
      </list>
      ...      
    </list>
    <list name="DescriptorItem">
      <attribute name="Name" value="TextArea" />
      <attribute name="GeometryItemName" value="AppCLabel" />
      <list name="Coordinates">
        <attribute name="Coordinate" value="0.0mm, 3.0mm" />
        <attribute name="Coordinate" value="10.0mm, 10.0mm" />
      </list>
      ...    
    </list>      
    ...
  </list>
</list>  

...

At first glance, the xml-fragment listed above might look a bit confusing. The same tags appear again and again and they sound rather generic.

Please do not worry about this. The Tensegrity Graph API must deal with many dynamic properties and therefore uses Attribute objects at runtime to pass around named values that aren't tied to any particular class.

Specification files such as geometry.xml, as well as others found in our framework, use an attribute paradigm when defining repository elements. Named tags, such as <SizeAdjustment> or <RoundEdges>, do not exist. Rather, this data is held inside different <attribute> elements where “SizeAdjustment” and “RoundEdges” are named xml-attribute values. The tags <list> and <set> enforce cardinality rules for child <attribute> tags, specifically the string found in the value part of the xml-attribute called name.

What this means for you is a generic approach at the cost of slightly decreased readability.