A Framework for GUI Program Portability Adam Faldalla Victor Matos Paul J. Jalics Payoff

Transcription

1 A Framework for GUI Program Portability Adam Faldalla Victor Matos Paul J. Jalics Payoff From the programmer's point of view, writing new GUI-based applications is more difficult than writing non-gui-based programs, especially when using object-oriented (OO) design, implementation methodologies, and programming languages. One concern is the proliferation of different GUI systems and languages, as well as wizards that generate GUI interfaces, which makes the portability of such applications across systems difficult. This article presents a case study of a genealogical family-tree application implemented in six different GUI systems, to illustrate the cross-gui platform portability problems, and a proposal is presented for making such applications more portable across various GUI systems. Introduction The success of the ubiquitous personal computer (PC)as a multi-purpose tool is largely due to the simplification of the graphical user interface (GUI). The new generation of interfaces is based on intuitive, self-explanatory graphics that invite the user to explore the application in a more natural way. Programming for GUI-based applications, however, is much more complex than writing non-gui-based programs. This difference is especially apparent when object-oriented (OO) design, implementation methodologies, and OO programming languages are involved. The programmer can only hope that the additional complexity of writing such programs is counterbalanced by the quality of the human interface and the application's ease-of-use once running. Most important, the proliferation of GUI wizards, systems, and languages makes the portability of such applications across systems difficult indeed. This article presents a case study of a genealogical family-tree application implemented in six different GUI systems, which illustrates the cross-gui platform portability problems. The authors also propose a solution for making such applications more portable across various GUI systems. Higher-level programming languages, such as C and C++, have made great strides in program portability from platform to platform and across operating systems in the past 10 to 15 years. This portability is no longer so prevalent in GUI-based programs, because the GUI system calls are so different on the various GUI environments. Furthermore, even if the GUI calls are the same, class libraries that help simplify GUI access are generally incompatible across different compiler. Finally, even general-purpose libraries, such as container class libraries, are significantly incompatible on different compilers. Some hope of alleviating the problems exists in this area: A number of GUI systems, such as PowerBuilder, are available on multiple platforms. Of even more significance, Java browsers and GUI class libraries are designed to be platform and operating system independent. Today's programmer need only look at current PC and workstation applications to appreciate the quality of such applications as word processors, spreadsheets, and accounting packages. Not only do these programs provide an attractive graphical interface, but in many cases they also can be used without any training, because they adhere to common conventions and are designed to be intuitive. Most of these programs can be categorized as GUI programs, because they use GUI and in addition are organized very differently than non-gui programs.

2 Non-GUI programs tend to be deterministic: The program starts at the top, and then often goes into a loop, inputting data and waiting for the data to be ready. It then processes the data and outputs some results. The program executes operating system requests, which on a typical UNIX system could be any of about 64 services mostly related to input/output, with disk file reads and writes the most highly requested a vast majority of the time. GUI programs, on the other hand, often consist of code to paint a screen or window and then put themselves in an endless loop, waiting for such events as mouse clicks, character inputs, the push of a button, or the selection of a menu item. When one of these events occurs, the appropriate event-handler procedure is executed. Most application code is placed either in the event-handling procedures themselves or in procedure calls made from the event-handling procedures. GUI programs typically call on system services that are more complex, consisting of over 350 services on Microsoft windows and about 700 services on OS/2 Presentation Manager. To illustrate the points covered in this article, a case study of the FamTree application will be discussed in some detail. It is a family tree application with three screens, each of which has menus: A People Screen This is used to input, view, and modify data about individual persons in the family data base, including name, gender, and birth and death dates (see Exhibit 1). A Relationships Screen This is used to input, edit, and view relationships between any two persons in the family data base (see Exhibit 2). A FamTree Report Screen This is used to produce ancestor trees and descendent trees of persons in the family data base (see Exhibit 3). The FamTree people Screen The FamTree Relationship Screen The FamTree Report Screen A student wrote the application as a research project, on a Macintosh using Think C, an object-oriented language similar to C++. The application consists of 2,636 lines of Think C code. The program makes use of an object-oriented class library (Think) to interface to the GUI on the Macintosh. The authors of this article started with very little knowledge of any of the seven GUI systems involved but with a solid background in computer science and systems programming. The project's goal was to learn about application portability by making this application work in the same way on seven different GUI systems: Macintosh Think C. Microsoft Visual C++ on Microsoft Windows. Borland C++ on Microsoft Windows. X-Windows using the OSF/Motif GUI System.

3 Tcl/Tk on X-Windows interfacing to the C++ application code. Microsoft Visual Basic interfacing to the C++ application code. Microsoft Access under Windows. Porting to Microsoft Visual C++: Port 1 The first port (port 1) turned the Think C Application code into C++ with minimal difficulties. The GUI interface, however, was totally different and hard to understand. Replacing it with the Microsoft Foundation Classes (MFC)GUI Application Framework usage turned out to be a challenge. The menu, window, and screen (dialog box) creations were all in Think C calls and were replaced totally by design work in the interactive application studio. The studio allowed the menus and the three dialog boxes to be created in minutes in a totally visual manner, with no code written at all and thus not a single GUI system call and none of the myriad of parameters usually required for such calls. The rest of the application contained a few dozen GUI calls throughout the various implementation functions that were difficult to identify and replace with MFC calls. The C++ compiler proved very useful in pinpointing C++ classes that were in the Think C application framework but not in the Visual C++ environment. In fact, there is very little, if any, commonality of GUI interfaces at this time across different systems. As a first step, these calls were commented out and analogous calls were sought in the MFC application framework. The use of a dynamically growing array to store the people data posed another problem. This was done on the Macintosh using a container class library class, which did not exist in the other systems. The immediate solution was to substitute the MFC class for such arrays, but the same problem recurred on the next port to Borland C++. Finally, a new class was created and used throughout the application. The class was implemented as a wrapper class for the MFC class, so that the next port would simply involve changing the implementation of this class. The use of this array throughout the application reduces the effort at each porting. Porting to Borland C++: Port 2 This port is very similar to port 1; the developers, however, were more familiar with the application this time. The menus and the three dialog boxes were again created by time spent in the Resource Workshop, in which the facilities were similar to those in the Visual C++. The rest of the GUI calls were reinvented, but this process was much simpler because the functions that needed to be done, in what places in the code, were very clear. Investigation of the functionality of the Object Windows application framework was timeconsuming, but the results most often were in the form of a line-for-line replacement of the MFC C++code with Object Windows calling code. Inconveniences included situations in which both of the systems have a facility for serializing or archiving the family data base, but the code to do it was considerably different, and the disk files written by one could not be read by the other. Porting to OSF/Motif and X-Windows: Port 3 Another important GUI system is X-Windows on UNIX systems; the system is available in OSF/Motif and Xlib libraries of subroutines. The starting point was the Borland C++ code from port 2, although the Microsoft Visual C++ code(port 1) would have required just the same effort. There is nothing analogous to the Application Studio in this case, and the

4 system does not have the polish of the previous two systems investigated, from the developer's point of view. The menu and dialog box creation was all done using Motif or Xlib calls from within the code, similar to what was done originally in the Macintosh program. The debugging tools were also inferior to the previous two systems, although easy printf and I/O stream debug outputs to the UNIX window were easier and very useful for debugging. The code worked in a relatively short time, although the original appearance of the dialog boxes from the Macintosh was hard to mimic, because of the power and flexibility of placement of controls in a window and because of all the dynamic resizing based on current data and window size. Porting to Tcl/Tk under X-Windows: Port 4 In search of a system more polished and automated than Motif and X-Windows on UNIX systems, the authors attempted an interesting scripting language called Tcl, from UC Berkeley, with an X-Windows add-on called Tk. The goal here was to keep as much of the C++ application intact but to do the GUI in Tcl/Tk. This necessitated isolation of the GUI portion from the family tree application itself; the family tree application manages the family data base of persons and their relationships, and it is able to produce reports of those relationships. Because only the GUI aspects are to be done in Tk and the application itself did not need to be rewritten in Tcl, identification was necessary of all the GUI code. The developers had to remove it and replace it with procedure calls to a new C++ module, PortableGui.C, that then made calls to Tk, which had access to all the GUI interfaces. Exhibit 4 depicts the organization of this Tk-based family tree application. The TCL/Tk Program Structure Creating the menus and dialog boxes was ultimately much simpler than creating them in Motif, but the same difficulties showed up as did in Motif, in terms of recreating the screens to appear exactly like the originals in the Macintosh. Whereas this system is not at all like the Application Studio, it is easier than Motif calls from C++ and can be recommended for a host of applications under X-Windows. PortableGui.C had 24 functions to replace the 24 different GUI calls found in the C++ application after the port to Borland C++. The functions included setting and getting the values of text boxes, radio buttons, adding to and deleting from list boxes, and finding the currently selected entry in list boxes. (Exhibit 5 contains a full list of the functions.) GUI Access Calls Needed by the FamTree Application SetFileName(char *newfilename); GetFileName(char*filename, int maxlen); SetRel(char *newrelname); SetPerson1(char*newname); SetPerson2(char *newname); GetGens(char *newnumgens,int maxlen); int GetAncestor(); AddFtree(char *newname,int position); AddList1(char *newname,int position); AddList2(char*newname,int position); AddList3(char *newname,int position); DeleteList1(int poisition); GetRoot(char *newname,int maxlen); SetRoot(char*newname); GetName(char *newname,int maxlen); GetBirth(char*newname,int maxlen); GetDeath(char *newname,int maxlen); int GetMale();

5 int GetPerson1B(); SetName(char *newname); SetBirth(char*newname); SetDeath(char *newname); SetMale(int); int GetListPos(int listboxid); This one part of the GUI interface was always called from the C++ family tree application code, it set some part of the screen or instructed the C++ application as to what data was in that part of the screen. The other part of the GUI interface was the event handler, which by this point in the project was coded in Tk; the event handler needed to call the C++ family tree application whenever a menu choice was made or a button was pressed by the user, such as the one that caused a person to be added to the family data base in the People dialog box. In these cases, no data is passed to the C++ application. Instead, a C++ event-handler function is executed, and it may call PortableGui.C for getting the needed GUI data. Porting to Visual Basic: Port 5 Perhaps the most interesting port was to Microsoft Visual Basic (VB). The GUI aspects of Visual Basic were very impressive. The developers wanted to experiment with linking a VB GUI with the C++ application as it existed after the Tcl/Tk port. All that was needed was to replace the implementation of PortableGui.C with an implementation that calls VB instead of Tk. After much experimentation, the developers used a Windows facility, called Dynamic Data Exchange (DDE), to link VB with the C++ application, as shown in Exhibit 6. DDE functionality is now provided as part of OLE. Each of the text boxes became a DDE server that would respond to DDE requests from the C++ application. In addition, the C++ application became a server to which one could send command requests from VB, such as for a menu selection or a button having been pressed. A DDE remote-execute facility was used to communicate with some other controls, such as list boxes and radio buttons. Structure of a VB Application Porting to Microsoft Access under Windows: Port 6 The final port was attempted because a data base package might be seen as a natural choice for implementing the FamTree application. Interfacing to the C++ application was not considered; instead, however, the application was rewritten in Access Basic. The menu and dialog box design was done in an application studio similar to Borland C++ or Visual C++. The application code was rewritten in Access macros (80 lines) whenever possible and in Access Basic (941 lines) for the rest. Recoding the application code in Access Basic took less time and trouble than anticipated, and the language itself is much improved over the not-so-impressive ancestor, Basic. The number of lines of code is only half as much as any of the other implementations. However, the GUI work of dialog boxes and menus is not easily measured in lines of code, because this design work is all done interactively. There is no printable output similar to the noninteractively written code to create menus and dialog boxes, as is the C++ code in the Macintosh and X-Windows implementations.

6 Effort Needed for Each Porting The following table shows the number of hours of work required for each of the portings of the family tree application. The authors had much experience with C++, some experience with an older DOS-based Borland GUI class library called TurboVision, and very little GUI programming experience outside of small modifications to a small X- Windows program. Environment Conversion Hours Code Size (Lines) Macintosh Think C Microsoft Visual C Borland C OSF/Motif+X-Windows Tcl/Tk VB-DDE-C Microsoft Access Environment Conversion Hours Code Size (Lines) Macintosh Think C Microsoft Visual C Borland C OSF/Motif+X-Windows Tcl/Tk VB-DDE-C Microsoft Access The average time for porting the application is about 98 hours. Surprisingly, the very first port, Microsoft Visual C++ on Microsoft Windows, required one of the shortest times, 79 hours: The application was unknown to the authors when this began, and the Visual C++ environment was new to them as well. Port 2, Borland C++, took the shortest time: 75 hours. The authors had no experience with Borland C++, but by this time the application was better known and the functionality and ways of Borland and Visual C++ were quite familiar. Furthermore, the authors had some experience with Borland's earlier C++ compiler and the TurboVision GUI for DOS, as well as with the Borland container class library. X-Windows, port 3, took 92 hours, much of which was spent learning to paint the screens, which had to be programmed. The scheme for programming screens is complicated. Multiple layers of window frames had to be created and positioned to place the controls on the screen as desired. The algorithm of recursively going through the layers of window frames, determining what each needs for its dimensions, and then sizing each accordingly is very powerful but also difficult to work with. Tcl/Tk took 82 hours, most of which was spent on learning the Tcl/Tk scripting language and how it interfaces to C++ application code. Results for a subsequent GUI applications would likely yield much better times. Visual Basic took the longest time, 157 hours, most of which was spent trying to establish communication between the C++ application and Visual Basic. Learning to make clients and servers of both the application and the Visual Basic GUI is certainly in tune with current trends. The authors would, however, avoid this combination of C++ and Visual Basic if at all possible. Finally, Microsoft Access took 102 hours, most of which was spent learning this fourth-generation tool, which is very much different from the other third-generation language tools. If the authors were to choose a tool for implementing a similar GUI

7 application, they might well choose Access in the hopes of recovering their investment in time in the second application. Separating the Application from the GUI The above ports of the FamTree application naturally emphasized the need for creating GUI application programs to be portable across widely varying GUI systems. This is especially true because there is little standardization of GUI systems across platforms, operating systems, and language systems. As one example, one company has built a large business application in Objective C on a Next but now may need to rewrite it all in a Windows 95 environment. The amount of work needed to make this conversion is staggering. The road to the portability of GUI applications begins by separating the code into three parts: The Application Code This is GUI system independent; it calls the interface to access GUI. The Interface Module This module is called from the Application module to access GUI services. It is completely different for each application and consists of 24 very short procedures for FamTree. The GUI Module This part handles menus, paints the screens, and responds to such events as button pushes and mouse movements by calling the Application module. This decomposition process is summarized in the GUI programs' portability framework, as illustrated in Exhibit 7. Such decomposition is imperative, because the GUI code would by default be intermixed all over the application. The first goal in a portable system is to design the application part of the code so that it needs only to be recompiled to move to another system. The interface module(i.e., as in PortableGui.C) must implement GUI calls of the given system and will be rewritten completely for each GUI system for which the application needs to be ported. Finally, the GUI part must be written from scratch for each system. Overview of GUI Programs Portability Framework For the FamTree application the X-Windows Motif version the application code is 1,506 lines of code, or 75% of the total, the interface is 166 lines, or 8%, and the GUI code is 344 lines, 17%. When porting this application, developers may find that 75% of the code can stay untouched, that the 8% Interface needs major modification, and that the 17% GUI needs to be rewritten from scratch. The GUI code is often automatically generated based on interactive design in an application studio or resource workshop. Therefore, in such environments, the code for the main program, the event handlers, and the screen and menu display is all written by the compiler system itself. In a more polished system, such as Microsoft Visual C++ or Borland C++, porting an application involves some interactive work. This means using an application wizard to make the main program, using a resource workshop to design menus and screens, and a class wizard to create the event handlers required and then insert calls to the application code for each event. After that, the user must adapt the interface code to that GUI system. Thus the actual lines of code that need to be rewritten come to about 10% for the above application. In the judgment of the authors, this is a very satisfactory level of effort for porting a GUI application. Finally, if an application is ported again to a third system, the porting work done on the first port is so similar that it can be done with very modest effort. The only challenge is to

8 learn the GUI class library calls for the new target system, which is needed to modify the Interface. Interfaces between the application and the GUI The People screen (which is used to enter people and their data and to view and modify this data) is an example of the interface that the application code uses to access GUI data. The application needs the following functions, which are implemented in PortableGui.C, where they make up 10 of the 24 interface procedures: [Tab]GetName(char * name, int maxlen) SetName(char* newname) GetBirth(char * bdate, int maxlen) SetBirth(char* newname) GetDeath(char * bdate, int maxlen) SetDeath(char* newname) int GetMale() SetMale(int maleis1) AddList1(char* newname, int position) DeleteList1(char * int position) Exhibit 1, the FamTree People screen, shows that all the application needs to get the data that the user has typed on the screen is to use the Get procedures, which typically return a character string whose maximum length is specified as the second parameter. At other times, when the user has selected a different person by clicking the appropriate entry in the list box on the right, the application code must find and put on the screen the data for that person, which is done by the Set procedures. Finally, the AddList1 procedure adds an entry to the list box on the right at the position specified, whereas DeleteList1 deletes an existing entry. The only functions supported are those the FamTree uses, so there might be a Set for some controls without a Get if the application does not require one. As an example of the use of the above procedures, clicking Peter Miller in the list box causes the application to set the Name text box to Peter Miller using SetName( Peter Miller ). The application sets the birth date text box to by executing SetBirth( ),then executes SetDeath( ), and finally executes SetMale(1). There is no need for Set or Get procedures for the four buttons ADD, CHANGE, DELETE, and CLEAR, because users can select these themselves, causing an event-handling procedure that is part of the GUI code to be executed. That GUI event-handling procedure, perhaps for example named OnAddButton will, in turn, call the application code procedure DoCommand(ADDBUTTON). As an example of the implementation of this Interface, the implementations of GetName and SetMale for Visual C++ are shown as they occur in PortableGui.C: GetName(XLPSTR cptr, int smax) { gppeople->getdlgitemtext(idc_ppl_edit_name,(lpstr) cptr, smax); return 0; } SetMale(int ind) { int checked=ind? IDC_PPL_RAD_MALE : IDC_PPL_RAD_FEMALE; gppeople->checkradiobutton(idc_ppl_rad_male, IDC_PPL_RAD_FEMALE, checked); return 0; } The code is GUI system dependent and changes with every port. Porting GUI applications requires substantial effort unless the program design clearly isolates the application code, the GUI code, and an interface module that allows the application code to talk to the GUI components. If the code is so organized, porting such

9 an application is simpler, the code to be changed is well isolated and identified, and the amount of code that needs to be modified is as little as 10% of the total lines. The beginner's efforts to port an application for the various GUI systems attempted are all close, with only about a 20% difference between all but one system. Also, the work is smallest for the two commercial GUI systems, in which most of the GUI work is done interactively in an application studio instead of writing code that calls GUI system calls to paint screens and menus. These produce larger code sizes, but most of the extra code is automatically generated. Surprisingly, the results for some of the latest 4GL tools, such as Access and Visual Basic took more time than the traditional C++ programming environments. One of the obstacles to portability is that the GUI Class libraries are completely different on every compiler, on every platform. Until more standardization is achieved in this area, the authors' proposition is to isolate GUI code in an interface module clearly identified and localized. Similarly, general-purpose class libraries, such as container classes, are a stumbling block to portability. Users can avoid using these class libraries altogether to improve portability, or they can create wrapper classes of their own that make use of the local class libraries in implementing the wrapper class. Therefore, the application is unaware of their use, and porting to a new system consists of simply replacing the class implementation with the best facilities in the target environment. A special case of the above relates to the highly useful facility in C++ class libraries called archiving or serializing data to files. Not only are these facilities totally incompatible in the various systems, but the data files they create are incompatible across compilers. So if the developer wants to make the data from an application also portable, these facilities should be avoided in favor of the traditional way of writing the data to normal files that are more easily portable. Experimentation such as was done in this project is most useful in, even essential to, staying current in this rapidly changing field of applied computer science. Author Biographies Adam Faldalla Adam Faldalla, Ph.D., is Assistant Professor of Computer and Information Science at the Cleveland State University. Victor Matos Victor Matos, Ph.D., is Associate Professor of Computer and Information Science at the Cleveland State University. Paul J. Jalics Paul J. Jalics, Ph.D., is Professor of Computer and Information Science at the Cleveland State University.

10

11

12

13

14

15