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.
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.
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.