INTRO SPECS TUTORIALS RESOURCES TOOLS ABOUT US CONTACT US
 
 

UIML 2
Tutorials

UIML 1
Tutorial 1
Tutorial 2

UIML 1 Tutorial 2:

  • More UIML language elements and structure.

  • Multiple styles for different interfaces.

  • Advanced styles using Swing.

  • Quick changes to modify the look of your interface.

We would like to design a paint program. Of course we will design the interface in UIML to maximize the flexibility once the program is complete. Noting that we may want to use the paint program on a palm-top or PDA, we will want the ability to create an interface with standard menus, and another with a "toolbar" that has iconized buttons.

To do this we assume that certain "commands" will always be in the menubar and other items will either go in the menubar or into a toolbar. Therefore we want two classes for these items.

The following is the ui description for the paint program.

<UIML>
<HEAD>
  <TITLE>Paint Program..loosely based on MS Paint</TITLE>
  <AUTHOR>Stephen Williams, Harmonia</AUTHOR>
  <DATE>12/2/97</DATE>
  <VERSION>0.5</VERSION>
</HEAD>

<APP NAME="Paint" CLASS="App">
  <GROUP NAME= "MainFrame" CLASS="frame">

   <GROUP NAME="File" CLASS="menu">     
     <ELEM NAME="New" CLASS="menuitem"/>
     <ELEM NAME="Quit" CLASS="menuitem"/>
     <ELEM NAME="Close" CLASS="menuitem"/>
   </GROUP>
   <GROUP NAME="Tools" CLASS="menuortoolbar">   
     <ELEM NAME="Line" CLASS="itemoricon"/>
     <ELEM NAME="Box" CLASS="itemoricon"/>
     <ELEM NAME="Oval" CLASS="itemoricon"/>
     <ELEM NAME="Trap" CLASS="itemoricon"/>  
     <ELEM NAME="Eraser" CLASS="itemoricon"/>
     <ELEM NAME="Pencil" CLASS="itemoricon"/>
     <ELEM NAME="Brush" CLASS="itemoricon"/>
     <ELEM NAME="Sprayer" CLASS="itemoricon"/>
     <ELEM NAME="Text" CLASS="itemoricon"/>
     <ELEM NAME="Magnifier" CLASS="itemoricon"/>
   </GROUP>
   <GROUP NAME="Help" CLASS="menu">     
     <ELEM NAME="PHelp" CLASS="menuitem"/>
     <ELEM NAME="About" CLASS="menuitem"/>
   </GROUP>

   <ELEM NAME="Painting" CLASS="PaintArea"/>

  </GROUP>
</APP>

<DEFINE NAME="Quit">
  <PROPERTIES>
    <CLASS VALUE="menuitem"/>
    <ACTION
        VALUE="MainFrame.VISIBLE=false"
        TRIGGER= "select"
    /> 
  </PROPERTIES>
</DEFINE>
<!-- Other commands to be added later -->
</UIML>

You will note that their are two command CLASSes called "menu" and "menuortoolbar". This allows us to make use two different styles to change the look of all the items with that class. Similarly, there are "item"s and "itemoricon"s.

The following style shows how we can define the same RENDERING for multiple style so that they look all the same in the interface. In this case both the "menu" and "menuortoolbar" CLASSes will be rendered as "Menu"s.


/*
  <AUTHOR>Stephen Williams, Harmonia</AUTHOR>
  <DATE>12/2/97</DATE>
  <VERSION>0.5</VERSION>
*/
APP.App{
    +TOOLKIT:            jfc;
    +RENDERING-PREFIX:   java.awt;
}
GROUP.frame {
  RENDERING: "java.awt.Frame";
  LAYOUT:    BorderLayout;
  SIZE:      "400,400";
  FONT-FACE: Serif;
  FONT-SIZE: 10;
  FONT-STYLE:Plain;
  CONTENT:   "Error:No Content";
}

GROUP.menu {
  RENDERING: "java.awt.Menu";
}

ELEM.menuitem {
  RENDERING: "java.awt.MenuItem";
}
GROUP.menuortoolbar {
  RENDERING: "java.awt.Menu";
}

ELEM.itemoricon {
   RENDERING: "java.awt.MenuItem";
}
ELEM.PaintArea {   
  RENDERING: "java.awt.Panel";
  ALIGNMENT: Center;
}

Because the CLASSes have the same rendering, the rendition of the items in the interface is as menus and menu items for both.

Those of you that use Java AWT often may notice that there is no mention in either the ui definition or the style of a "MenuBar". This feature is taken care of automatically. Since a frame can have, at most, one MenuBar, it is assumed that any GROUPs with a RENDERING=Menu go into that one MenuBar. This allows you to assign menus at any point...or change the RENDERING of a GROUP of buttons (or something else) to a Menu without having to rearrange the ui definition.

All of the items with CLASS=menuitemoricon show up in the Tools menu. Because the Help menu information comes after the Tools info in the ui definition, the Help menu comes third.

Recall that we would also like create an interface with a toolbar as well. We can reuse the ui definition with no modifications. However, we need some extra elements that are not available in AWT. These elements include toggle buttons and the ability to put icons in the buttons instead of text. For this we will need to use Swing (the JFC widgets for jdk 2.0).

The new style is listed below. You will immediately note that the RENDERING-PREFIX is not used (the APP.App requires it but it starts with a '-' sign), but the fully qualified name is inserted for each RENDERING. This is required now, but will not be in future versions.


/*
  <AUTHOR>Stephen Williams, Harmonia</AUTHOR>
  <DATE>12/2/97</DATE>
  <VERSION>0.5</VERSION>
*/

APP.App{
    +TOOLKIT:            jfc;
    -RENDERING-PREFIX:   java.awt;
}
GROUP.frame {		/* From content database:  CONTENT */
  RENDERING: java.awt.Frame;
  LAYOUT:    BorderLayout;
  SIZE:      "400,400";
  FONT-FACE: Serif;
  FONT-SIZE: 10;
  FONT-STYLE:Plain;
  CONTENT:   "Error:No Content";
}

GROUP.menu {		    
  RENDERING: "java.awt.Menu";
}

ELEM.menuitem {	     
  RENDERING: "java.awt.MenuItem";
}

GROUP.menuortoolbar {	     
  RENDERING: "java.awt.Panel";
  SIZE:      "400,20";
  ALIGNMENT: "North";
  LAYOUT:    GridLayout;
  +BACKGROUND: "lightgray";
  ROWS:      1;
}

ELEM.itemoricon {	     
  RENDERING: "com.sun.java.swing.JToggleButton";
  SIZE:      "30,30";
  CONTENT:   " ";
  TEXT-HORIZONTAL: Center;
}

ELEM.PaintArea {            
  RENDERING: "java.awt.Panel";
  ALIGNMENT: "Center";
}

A few notes on choices. In general, it is better to pick the AWT component if you don't need the extended features of Swing. This is especially true for containers (e.g. panel, frame, window). In this case the only Swing component is the JToggleButton which gives us two new capabilities; embedded images and maintaining button state. There is also an added bonus ---Tool Tips---.

You may have noticed that the Frame layout is BorderLayout and the toolbar is in GridLayout. Why not FlowLayout? The answer is that, right now, there is a conflict with the ALIGNMENT attribute. In GridBagLayout and BorderLayout, the ALIGNMENT attribute is associated with the children of the layout GROUP: but, in FlowLayout, the ALIGNMENT is associated with the actual layout GROUP. Because BorderLayout uses "North,East,West,South, and Center" as values, and FlowLayout uses "Left,Center and Right", there would be a name conflict. This problem will be fixed in later versions. NOTE: If you need a FlowLayout panel inside a BorderLayout panel or frame you can accomplish this by "buffering". Create another panel that is nested inside the BorderLayout, but outside the FlowLayout and give it a layout of GridLayout. This grid panel will have only the FlowLayout panel w/in it and the interface will behave as it SHOULD with just the Border and Flow panels.

We have waited until now to show you the Content Database because it has all of the values for both the Toolbar and Menu version. We can do this and use the "-key" to distinguish between them (I used "NoSwing" and "Swing" as keys).

# Records to initialize content data base for Ex8-1 from Nutshell book.


# Stephen Williams (12/2/97)
# Record format:  Key, Name (from .ui file), Attribute, Value
#
* MainFrame CONTENT Harmony Paint
#
* File      CONTENT File
* New       CONTENT New
* Quit      CONTENT Quit
* Close     CONTENT Close
#
#-------Tools Menu--------
NoSwing Tools     CONTENT Tools
#
NoSwing Line      CONTENT Line
NoSwing Box       CONTENT Box
NoSwing Oval      CONTENT Oval
NoSwing Trap      CONTENT Trap
NoSwing Eraser    CONTENT Eraser
NoSwing Pencil    CONTENT Pencil
NoSwing Brush     CONTENT Paint Brush
NoSwing Sprayer   CONTENT Spray Gun
NoSwing Text      CONTENT Insert Text
NoSwing Magnifier CONTENT Zoom
#
#-------Help Menu--------
*       Help      CONTENT Help
#
*       PHelp     CONTENT Contents and Index
*       About     CONTENT About Paint
#
* Painting SIZE    400,400
#-------------------SWING STUFF
#-------Tools Menu--------
#Swing Tools     CONTENT Tools
#
Swing Line       IMAGE   Icons/Line.gif
Swing Line       TOOLTIP Line
Swing Box        IMAGE   Icons/Box.gif
Swing Box        TOOLTIP Rectangle or "Shift" for Square
Swing Oval       IMAGE   Icons/Oval.gif
Swing Oval       TOOLTIP Oval or "Shift" for Circle
#
Swing Trap       IMAGE   Icons/Trap.gif
Swing Trap       TOOLTIP Object Trap
Swing Eraser     IMAGE   Icons/Eraser.gif
Swing Eraser     TOOLTIP Eraser
Swing Pencil     IMAGE   Icons/Pencil.gif
Swing Pencil     TOOLTIP Draw with sharp pencil
Swing Brush      IMAGE   Icons/Brush.gif
Swing Brush      TOOLTIP Draw with paintbrush
Swing Sprayer    IMAGE   Icons/Sprayer.gif
Swing Sprayer    TOOLTIP Draw with spray gun
Swing Text       IMAGE   Icons/Text.gif
Swing Text       TOOLTIP Add text
Swing Magnifier  IMAGE   Icons/Magnify.gif
Swing Magnifier  TOOLTIP Zoom In/Out on image

If you look at the content file you will actually see three keys. The first two are "Swing" and "NoSwing", but there are also a bunch of lines that begin with "*". This is because, with the exception of the "Tools Menu" section, all of the database entries are the same. The "*" key is a default key. If the renderer cannot find the values for a particular element under the given key name, it looks for one with a "*" key. There is also a "**" key. The "**" means Override any existing values under the named or default key. This can be used for testing or for temporarily enabling/disabling some function for everyone.

The "Tools" section has "CONTENT" attribute for the "NoSwing" key. This fills in the text for the menuitem. For the "Swing" key, the "CONTENT" is replaced with "IMAGE" and "TOOLTIP". The image places the icon in the button instead of text. "TOOLTIP" adds a message that pops up when that button is in-focus.

The resulting screen when using the second style, a key of "Swing" and the original ui definition looks like:

Now that we have gone through ALL of this trouble, what happens if someone says: "But I wanted the tools down the side, not on the top." Exactly how much trouble is it to make that kind of modification?

This is actually very simple. We only need to change WHERE the toolbar (which is a panel) is located in the parent, and change the Layout of the toolbar to indicate that we are restricting columns instead of rows.

The following shows the changes: (the crossed-out lines are removed...the bold lines are inserted).


/*
  <AUTHOR>Stephen Williams, Harmonia</AUTHOR>
  <DATE>12/3/97</DATE>
  <VERSION>0.6</VERSION>
*/

GROUP.frame {		
  +TOOLKIT:  jfc;
  RENDERING: java.awt.Frame;
  LAYOUT:    BorderLayout;
  SIZE:      "400,400";
  FONT-FACE: Serif;
  FONT-SIZE: 10;
  FONT-STYLE:Plain;
  CONTENT:   "Error:No Content";
}

GROUP.menu {		    
  RENDERING: "java.awt.Menu";
}

ELEM.menuitem {	     
  RENDERING: "java.awt.MenuItem";
}

GROUP.menuortoolbar {	     
  RENDERING: "java.awt.Panel";
  SIZE:      "400,20";
  ALIGNMENT: "North";
  ALIGNMENT: "East";
  LAYOUT:     GridLayout;
  +BACKGROUND: "lightgray";
  ROWS:       1;
  COLUMNS:    1;
}

ELEM.itemoricon {	     
  RENDERING: "com.sun.java.swing.JToggleButton";
  SIZE:      "30,30";
  CONTENT:   " ";
  TEXT-HORIZONTAL: Center;
}

ELEM.PaintArea {            
  RENDERING: "java.awt.Panel";
  ALIGNMENT: "Center";
}

 

Now the interface looks like this:

You may have noticed in the toolbar examples that the Help menu is on the MenuBar immediately after the File menu. As we discussed earlier, any Menu added is put into the ancestor Frame's MenuBar in the order that it occurs.

 

© 1999-2000 UIML.org (all rights reserved)