Laserfiche WebLink
The code that is not related to the GUI must be written by the developer. Typically, the GUI builder <br />will ask the user to insert code for callbacks. For example, if a " " push-button <br />quit_button <br />created using the GUI builder requires the name of a function to call when the button is pushed, the <br />GUI builder will prompt the user for that function name. The developer must then write the code for <br />that function and must ensure that the function accepts the proper arguments. If the function is one <br />that can be developed by the GUI builder the user will not need to write code externally. <br />GUI builders fall into two main classes: <br />(1)GUI builders that emulate a windowing system. <br />(2)GUI builders that rely on the native graphics environment (e.g., use the X Window System <br />on UNIX systems and Microsoft Windows on PCs). <br />GUI builders that emulate a windowing system essentially duplicate all windowing capabilities in <br />proprietary code. Such a system allows the GUI builder to offer capabilities that may not be offered <br />by a particular system (such as the X Window System); however, the developer must rely on the GUI <br />builder for all functionality and may not be able to use the native system. <br />GUI builders that rely on the native graphics environment are somewhat limited by the features of <br />the native environment. For example, if a ?sprocket button? is available under the X Window <br />System, then it is available to the developer; however, such a button may not be available from <br />Microsoft Windows unless the GUI builder software has made provisions to create this type of <br />button from other native Microsoft Windows features. If necessary, the developer can still access the <br />native environment. <br />Regardless of the type of GUI builder, a common element exists in the final application. This <br />element is an intermediate layer of code between the native windowing code and the application <br />code. For example, one way to create a window in the X Window System is to call the routine <br />. The GUI builder might have a routine called instead. <br />XCreateSimpleWindow CreateWindow <br />Once the application uses the GUI builder code, it is dependent on that code. <br />A portable GUI builder is one which allows a single copy of code to create the same GUI on <br />different windowing systems while using the ?look and feel? of that windowing system. For <br />example, the routine described above would be called the same way regardless of <br />CreateWindow <br />whether the X Window System or Microsoft Windows is used. However, the code for the <br /> routine would be different for each type of windowing system. The responsibility <br />CreateWindow <br />for ensuring that the routine works on different windowing systems is left to the <br />CreateWindow <br />provider of the GUI builder software, and would require that provider to create and support a GUI <br />library on each platform (e.g., Hewlett Packard, SGI, IBM, DEC, PCs, Macintosh), windowing <br />system (e.g., X Window System and Motif, Microsoft Windows, Macintosh) and for each compiler <br />on the supported platforms (e.g., C compiler on each UNIX platform, a nd multiple compilers on <br />PCs). <br />Because computing environments are moving toward a networked environment in which different <br />types of machines run graphically oriented programs, it is highly desirable to be able to develop a <br />GUI once and be able to port it to different windowing systems with minimal effort. However, as the <br />material above illustrates, GUI builders must contend with a large number of issues, and can <br />4 <br />A275 07.28.94 1.05-15 Malers <br />