| X-Designer User's Guide |    
|
| X-Designer User's Guide |
|
| C H A P T E R 24 |
|
Command Line Operations |
This chapter describes the command line switches understood by X-Designer. They fall into two categories: those which affect X-Designer running interactively and those which can be used for command line code generation. This chapter also describes the command line versions of XD/Capture and XD/Replay and the commands provided for conversion of UIL and GIL code into X-Designer save files.
The following command line switches are available:
|
Display X-Designer version information (the program is not run) |
For further information on starting X-Designer in Microsoft Windows mode see Starting in Microsoft Windows Mode.
Using a private colormap is useful if you intend to use a lot of colors in the pixmap editor. See Editing Pixmaps for a description of the pixmap editor. If you do select this option, however, you may observe strange color effects in other windows.
xdesigner [-csepAKCSEulbarmRMFWXJ -pixmaps -xml [code_file] [-properties [file]]] [-G directory [-O]] [-windows] -f filename
|
Generate all pixmaps to separate .xpm files in the directory specified as code_file |
|
code_file represents the file to be generated. If you do not specify a code_file, X-Designer generates code to the last target file specified in your source file for the given language.
For Java code generation (-J) and pixmaps (-pixmaps) multiple source files may be generated and the names of the code files are the names of the classes (for Java) or the pixmaps used in your design. Therefore, code_file is the target directory for these source files.
filename represents the design file (.xd) to be used as a source for the code generation. You must always specify a filename. If you do not also specify a code_file, use the -f separator to indicate that you are providing only one filename.
The -windows switch specifies Microsoft Windows mode. For further information on starting X-Designer in Microsoft Windows mode see Starting in Microsoft Windows Mode.
The M, F, W and R switches are only used in conjunction with the -windows switch.
xdesigner -c foo.c -f foo.xd
generates C code from the design in foo.xd into the file foo.c.
xdesigner -c -f foo.xd
generates C code from foo.xd into the target file that was specified the last time C code was generated from foo.xd via the Generate Dialog.
You can use a single command to generate multiple files using one of the following forms:
xdesigner -c -e -s -f foo.xd
xdesigner -c <c_file> -e <extern_file> -s <stub_file> -f foo.xd
X-Designer exits with status zero if successful and non-zero status if it fails to generate the code for any reason.
X-Designer must be connected to an X server to generate code from the command line. Usually command line code generation does not create any visible windows but windows do appear momentarily on the server screen for designs containing certain types of widgets, such as ScrolledList and ScrolledText and when generating Microsoft Windows code.
If you don't specify a code_file, X-Designer relies on the filename saved in the design file for the specified type of code. The filename is only saved when you specify it on the Generate Dialog and then save the file. If you have never used the Generate Dialog to generate this type of code from the design file, X-Designer produces only an error message.
In all cases, the generate toggles are set as they were last saved in the design file. If you have never generated this type of code from the design file, default toggle settings are used.
XD/Replay (when used to record user actions) is supplied as a stand-alone application called xdrecord.
The following line shows how to use xdrecord:
xdrecord -f MyRecordScript AnApplication
MyRecordScript is the name of a file into which a script recording the session will be saved. AnApplication is the name of the application you wish to record.
The following line shows how to use xdreplay:
xdreplay -f MyRecordScript AnApplication
You can leave out the filename argument for both xdreplay and xdrecord. xdrecord will then output to standard output and xdreplay will read from standard input.
The following table shows the full list of command line switches available for both xdrecord and xdreplay:
XD/Capture can be started directly from the command line
The following line gives an example of how xdcapture can be used:
xdcapture AnApplication
This displays the Capture dialog and runs the application, AnApplication.
The following table shows the full list of command line switches available:
The uil2xd filter converts UIL source code to X-Designer save files. It reads UIL source from standard input and writes a save file for X-Designer on standard output.
By default, uil2xd generates a save file for the latest release of X-Designer. The command line synopsis is:
uil2xd [-XeltxywhpsaAD] [-m { 1.2 | 2.1 | 2.1kit}] [-M map_file] [-P primary] [-I include_dir]
The command line options are listed in the following table:
uil2xd does not handle the following constructs:
Except for the imported keyword, uil2xd simply ignores these constructs.
The gil2xd filter converts Sun Microsystems Inc.'s DevGuide save files into X-Designer save files. The converter works by mapping the OPEN LOOK objects into Motif objects. It reads GIL source from standard input and writes a save file for X-Designer on standard output.
It generates a save file for the latest version of X-Designer. The command line synopsis is:
gil2xd [-xywhpsaX]
The command line options are listed in the following table:
gil2xd does not handle connections other than function calls and the simple notify actions for buttons which can be mapped to links. Other connections are reported as warnings. gil2xd simply ignores these constructs.
Few of the mappings from OPEN LOOK objects to Motif widgets are straightforward as they depend somewhat on their context. The fundamentals of the mappings are outlined below.
Maps to a DialogShell with a MainWindow child with a Form work area.
Maps to a DialogShell with a Form child.
Maps to a DrawingArea which will be a child of a ScrolledWindow if horizontal-scrollbar or vertical-scrollbar is true. An associated PopupMenu is created as a child of the DrawingArea.
Maps to a Menu. If the menu has a menu-title attribute, the first child widget will be a Label which shows the title, followed by a Separator. The menu items are mapped to additional children of the Menu. If the menu-type attribute is command, the widgets will be ToggleButtons; if they have an associated menu they will be CascadeButtons, otherwise they will be PushButtons. As X-Designer has no concept of shared menus, menus which are referenced from more than one place will map to copies of the Menu.
Maps to a PushButton if it does not have a menu, otherwise it maps to a CascadeButton. This CascadeButton will be created in a MenuBar. CascadeButtons which have the same y co-ordinate will be created in the same MenuBar. The MenuBar will be created in an enclosing MainWindow if possible, otherwise it will be created at the appropriate location.
Both map to a Scale. Separators will be added as children for tick marks and Labels may be added to show the min-value-string and max-value-string. The min-value and max-value map to the Scale's minimum and maximum fields respectively.
Maps to an OptionMenu if setting-type is stack, otherwise maps to a RowColumn. The choices are mapped to PushButtons in an OptionMenu and ToggleButtons in a RowColumn. For exclusive and non-exclusive settings the ToggleButton is adjusted so that the indicator is not used (shadowThickness = 2, marginLeft = 0, indicatorOn = false).
Maps to RowColumn with Label and Text widgets. Text will be ScrolledText if text-type is set to multiline.
Maps to a ScrolledList. If the list has a label attribute set, the ScrolledList is created as a child of a RowColumn with a Label child which displays the label. If the list has a title attribute, the ScrolledList is created as a child of a Frame with a Label to display this title.
Maps to a Form which has each of the stack members as children. The children are attached to both sides of the Form.
Maps to a RowColumn which has each of the member widgets as children.
Once the gil objects have been mapped to widgets the attributes must be mapped to appropriate widget resources. The following resources are always mapped:
The width and height resources are only used if the -w or -h flags are set when gil2xd is run. The x and y resources will be output if the -x or -y flags are set. However, for widgets which are children of Forms the x and y co-ordinates will be used to calculate default Form attachments to preserve the approximate layout.
Note that many of the Motif manager widgets will ignore explicit x, y, width and height resources anyway. The gil2xd filter can be used without any of the runtime flags to produce an adequate layout which can be easily modified using X-Designer.
Other resources are mapped to the nearest possible resource.
Actions which have a CallFunction function_type are mapped to callbacks where appropriate.
There are a number of other gil actions which are not detailed in this list. These are not supported by the filter as there is no appropriate Motif callback.
Notify actions for PushButtons which have a Show, Hide, Enable or Disable connection are mapped to the appropriate X-Designer link.
| X-Designer User's Guide | 817-5581-10 |
|
Copyright © 2003, Sun Microsystems, Inc. All rights reserved.