|
|
![]() |
|
|||||
|
|||||||
|
|
|||||||
|
UIML
2 UIML
1 |
UIML 1 Tutorial 2:
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.
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.
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.
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";
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) |