Xforms Marries Perl

How to add a powerful graphical user interface to Perl scripts
Going from the Picture to the Perl Code

Now we have finished designing the application, and we can save it as a file called pbook. This operation generates four (or more, based on how you set it up) files. The one of interest to us is called pbook.pl (Listing 1). If we ever want to modify our design, the .pl file is regenerated; thus, we should not modify this file, as any changes to it would be lost. Rather, in our code, we need to require the file to set up our form for us.

The Essentials of the Code

For a Perl script to use Xforms4Perl, all you have to do is add the line:

use X11::Xforms;

to the top of your Perl script. This command dynamically loads everything that needs to be loaded. If you want to access the XFontStruct or XEvent structures, then you will also need to add use X11::XFontStruct or use X11::XEvent. Before doing anything involving the Xforms library, you must call a function so that Xforms can initialize all of its internal variables, etc. This is done by calling

fl_initialize('Phone Book');
and giving it the title of the application you want. You set up all the forms you need by making calls to subroutines, such as:
which have been generated by fdesign and fd2perl. Then, add whatever initialization code you need. For example, if you make a “slider” using fdesign and need to set the range of values of the slider based on some input, you will need to call fl_set_slider_bounds with the proper parameters. After you have finished configuration, you're ready to show the form to the user. To accomplish this, make the call:
"Phone Book");
There are also commands to make the form disappear, so it's fairly easy to handle multiple forms. The options you feed fl_show_form include the specific form you wish to display (remember we called ours “list”), options for the window manager and a title. Once everything is set up and you're ready for the user to interact with the GUI, you then keep calling the function fl_do_forms. Thus, the minimal amount of code you need to display this form is:
use X11::Xforms;
require "pbook.pl";
fl_initialize('Phone Book');
fl_show_form($list, FL_PLACE_FREE, FL_FULLBORDER,
                                'Phone Book');
while(1) {fl_do_forms};
The actual interaction the user has with the GUI is accomplished via callback functions. Keep in mind this represents the bare essentials of a basic mode of using Xforms4Perl, and there are many other ways of using the libraries. The Xforms manual should be consulted for more advanced methods.

Back to the Phone Book

Let's look at how our phone book program is now pieced together. A full listing can be found in Listing 2. First, look at the entire main routine. In addition to the above listing, we've added the calls to two subroutines to initialize the browser before displaying it with the fl_show_form function.


Figure 3. Phone Book

As you can see, most of the program is handled in subroutines. First, we load the libraries and initialize the program. The call to create_form_list sets up the form we pieced together using fdesign. The call to load_data loads the data from a file in the user's home directory called .pbook. The format for this file has been arbitrarily set up to contain one phone book entry per line with the data delimited by colons. (Assume the user would never use a colon in any entry. See Figure 3.) A sample entry (one line) from .pbook would look like this:

Suhad:414 555-1234:2014 S 102nd St:Milwaukee,
WI 53227:sniazi@ucsd.edu

Now that the data is loaded, the update_browser call clears the browser and adds the newly loaded names to the browser list. To show the phone book to the user, we make the call to fl_show_form, and then loop through fl_do_forms to let Xforms take over.

The rest of the interaction with the user is handled through callbacks, which include adding or updating entries, saving the new entries, displaying information and quitting the application. The complete code is shown in Listing 2, and it's fairly evident how the callbacks work together, given Xforms' verbose function names. For example, fl_get_input gets the data from an input field, and fl_set_input sets it to some value. To get a better feeling for all the functions available, you can print out the 200-page manual that comes with Xforms; it makes an invaluable reference.

Although it should be fairly easy to guess what the code in Listing 2 does, there are a few things I'd like to mention and clarify. First of all, when the data is loaded, it is kept in a data structure called $DATA which is a pointer to an anonymous hash containing the names of the people in the address book. In turn, each of those names is a pointer to another anonymous hash containing the phone number, address, etc. For example, to access Tom's phone number, you would use $DATA->{'Tom'}->{pnumber}. Because we chose to handle the storage and organization of data using this method, we run into a slight problem. If we modify the name of an entry (i.e., change Tom to Tommy), the program thinks it is dealing with a new entry (because the hash's key is changed), and thus, two entries are made: one based on the name Tom and one based on the name Tommy. I leave it as an exercise for the reader to find a solution for this problem.

Most subroutines use either the fl_set_input or fl_get_input calls to manipulate the data you see. The only complicated call is


This call is used to determine the highlighted name from the browser. For example, in Figure 2, the highlighted name is Suhad. In order to do that, we need to give fl_get_browser the line number in which the entry appears. To get that number, we make a call to fl_get_browser_line which returns with the current highlighted line number.

Another thing to note is that rather than having a “save” button, this phone book assumes you wouldn't make a mistake. Thus, it saves the data every time you click on either the Update button or the Delete Entry button. A backup of the last saved file is kept as .pbook.bak in case of a problem, but the user has to restore the backup himself—it's not automatic.

All listings referred to in this article are available by anonymous download in the file ftp.linuxjournal.com/pub/lj/listings/issue55/2024.tgz.

Reza Naima (reza@reza.net) spent the last year working at Cisco Systems in charge of web server security. Among his duties were ensuring any deployed code was secure, developing security standards and writing automation applications. He just left Cisco to go on a 3.5 month trip around the world, returning in mid-September.