Next: Tcl/Tk Up: The Design of XF Previous: Existing interface builders

# The XF design

Thanks to the great flexibility and the simple handling of Tcl/Tk , and a very instructive and conceptionally clean predecessor (named BYO ), it was easy to implement XF . There exists no real design of XF . It was inspired by the simple (but very powerful) concept of BYO , and a further development that I have done named XASK . This program provided a simple language for building a certain type of simple graphical interfaces. These interfaces were connected with traditional (non graphical) applications. As there was no interface builder for this system and the language was very limited, the arrival of Tcl/Tk and BYO

lead to the decision to switch to this more powerful environment.

Three points were most important for the design of XF . The programm was supposed to be able to manipulate a running application. This was important because this is the only way to guarantee that the user really gets what he wants, and can test the application without having to compile it or to switch to a simulation mode. This restricted the choice of implementation languages, as the application must be open for modifications while it is running. One way would have been to simulate the running application by writing an interpreter for the implementation language (like C). The other way was to use an interpreted language. The second alternative was chosen. At this point, there were two alternative languages available. The first language was Tcl/Tk , a package containing a scripting language and a -like widget set. The second language was elk, a scheme interpreter with an interface to the X toolkit and widget set based upon the X toolkit (This system is part of the X contributed software). Due to a greater acceptance in the community (and greater acceptance by the author of XF ), Tcl was chosen.

The idea of manipulating an application with an interface builder while it is running was taken from BYO . This approach has the advantage that it reduces the amount of data that has to be used to store the contents of the currently developed application. As all changes are directly applied to the program, the program itself contains all information which is necessary to create a Tcl/Tk file containing the program definition. BYO achieves this by using a Tk feature to communicate with the application running in a different interpreter (see figure ). This approach allows the simultaneous manipulation of several applications.

Figure: BYO design

XF chooses a different approach. It uses one interpreter for both programs (XF and the application to be built). The name spaces of both programs (variables, procedures and widgets) are separated by naming convention (see figure ). This was originally done to reduce the communication traffic, and to reduce the complexity of the application. As the approach of BYO is more flexible, XF

will probably be adapted to (also) support this type of manipulating an external application.

Figure: XF design

The second very important point was that the developer is supported as much as possible. Newly created widgets are created with reasonable default parameters, to prevent the need of changing every newly created widget. Nevertheless, every aspect of the application can be changed with XF . If this is not possible in a certain situation, or the user does not want so much support, it is always possible to change the code directly (by hand in an editor). While many interface builders don't allow the manipulation of the generated code, directly changed code can be reused with XF

without any restriction.

The third important point for the design of XF was to allow the extension of XF . There are several well defined internal interfaces, where additional features (like new layouting dialogs, or new widget configuration dialogs) can be added to XF . Furthermore, the user is able to adapt most aspects of XF via interactive dialogs. This includes the menubar and iconbar layout, the bindings that are used to manipulate the application program and various aspects of the XF dialog boxes.

The design of the interface of XF itself was also a very important task. Like most interface builders, XF displays the available widget classes in some kind of main window. From here, all features of XF are activated. The various features are implemented as additional dialogs, that are popped up when they are activated. All configuration and layouting dialogs are nonmodal, so that the user can change parameters and the layout of various widgets simultaneously.

Next: Tcl/Tk Up: The Design of XF Previous: Existing interface builders