Platform-independent GUI library

A PIGUI (Platform Independent Graphical User Interface) package is a software library that a programmer uses to produce GUI code for multiple computer platforms. The package presents subroutines and/or objects (along with a programming approach) which are independent of the GUIs that the programmer is targeting. For the purposes of this article, a PIGUI must support several GUIs under at least two different operating systems (so just supporting OPEN LOOK and X11 on two Unix boxes doesn't count). The package does not necessarily provide any additional portability features. Native look and feel is a desirable feature, but is not essential for PIGUIs.

Considerations

• Most (possibly all) of the PIGUIs will slow the execution of the resulting code
• Programmers are largely limited to the feature set provided by the PIGUI
• Bugs in any package (PIGUI or otherwise) filter down to production code
• Fewer people know how to code any specific PIGUI than do a platform-specific GUI (e.g., Microsoft Windows), limiting the number of people who can give advanced help
• The PIGUI only deals with the GUI aspects of the program, leaving the programmer responsible for other portability issues
• If the vendor goes out of business there may be no further support, including future OS enhancements, though availability of source code can ease but not eliminate this problem. See the list of unavailable or unsupported packages

Alternative approaches

See also: Rich Internet application

Web browsers offer a convenient alternative for many applications. Web browsers utilise HTML as a presentation layer for applications hosted on a central server, and web browsers are available for pretty much every platform. However, some applications do not lend themselves well to the web paradigm, requiring a local application with GUI capabilities. Where such applications must support multiple platforms, PIGUI can be more appropriate.

Instead of using a PIGUI, developers could partition their applications into GUI and non-GUI objects, and implement the GUI objects in the native API. Then, when porting, only the GUI objects need to be rewritten for the new platform.

There are some software developers who recommend this course of action, as it produces a better fit on each platform and eliminates the overheads often associated with PIGUI toolkits. Obviously, this may require more effort in both the initial development and in ongoing maintenance (no single base of source code). It also means learning how to code for every target platform. Not (usually) a trivial task, hence the market for PIGUI packages.

(NB: Partitioning your design into GUI and non-GUI objects is a good thing to do anyway)

Language choice

There are PIGUI packages for multiple programming languages, including C, C++, Smalltalk, Java, Ada, Tcl, and Python. Most (all?) new PIGUI packages will be developed in Object-Oriented (OO) programming languages, as GUI work is ideally suited by the advantages of OO (especially inheritance / reuse). The bulk of existing kits are in C++, due to the popularity of that language, with many still in C but supporting C++.

Many C programmers will look at the purchase of a PIGUI package as a great opportunity to migrate to C++. If the library takes full advantage of C++, the programmer will have to use C++ methodologies (not just a C++ compiler with C syntax) to use it. When one ports a C program to such a library, one should expect to invest a significant amount of effort learning about (and modifying one's code to take advantage of) classes, inheritance, and constructors in order to complete the port. Of course, if one wants one's C code to become C++ code, this is a necessary exercise anyway.

Other issues to consider

The difference in GUI programming is most likely the greatest hurdle when programming for cross-platform portability, but it is not the only hurdle. Other issues often not dealt with by PIGUI packages, include (but may not be limited to):

• byte alignment (little-endian vs big-endian) of data types in files and over network connections
• (more generally) data formats, e.g. non IEEE floating point
• memory management (e.g. 64k segment limitations)
• text file end-of-line termination (CRLF, LF, CR, RS, ...)
• directory / folder navigation and file management services
• support for multi-threading
• Inter-process communication
• system level functions (OS specific)
• support for Unicode or other character encoding schemes

When developing an application that may be ported to more than one platform (even if those platforms are the 16, 32 and 64-bit versions of Microsoft Windows), you should be aware of the differences between the target platforms before development commences.

User interface approaches

Most, if not all, PIGUI packages take one of three approaches to providing platform independence. The two most common approaches are the `layered' and the `emulated' user interface but an up-and-coming approach is `API emulated' interface.

Packages using a layered interface access native, third party, GUI-building toolkits to provide the look-and-feel compliance for each particular GUI. Layered user interfaces have the advantage that, since they depend on other products which concentrate on a single GUI, they have to provide less software (and, hence, are usually less expensive) than emulated interfaces. Layered interfaces are also more likely to get the native look-and-feel correct on all platforms.

In an emulated user interface, the PIGUI's resultant code produces low-level calls and all the look-and-feel compliance is handled by the PIGUI software itself (e.g., for OpenWindows support, the software would NOT produce an XView program that must be compiled with the XView toolkit; the software would produce code that interfaces directly with X intrinsics). To provide an emulated user interface, a package provider has to develop a lot of extra code for look-and-feel support. Emulated user interfaces have the advantage that someone on a X11 workstation, for example, can see how the Macintosh-style UI will look (since the look-and-feel is part of the product). Emulated interfaces have the opportunity to provide a faster GUI than does a layered interface; in addition, it does not require you to purchase (or learn how to use) other packages to build GUI software.

A third approach to platform independence is emulating one of the supported target's APIs (usually, the Microsoft Windows API) to target other GUIs. With one of these products, one would program using the emulated API and the code would be (to the extent to which the product provides portability) portable to other GUIs.

Features

PIGUI packages are pretty similar in their basic functionality; they each provide subroutines or objects that allow the user to build windows, buttons (regular as well as radio buttons and check boxes), menus, and the like. Some areas of differentiation are:

• support for the platforms you need,
• the choice of implementation language,
• availability of source code,
• support for printers and other devices,
• support for various character encoding schemes including Unicode,
• capability to support draw-package-like features,
• bitmap (and icon) support,
• the approach to platform independence,
• nifty high-level widgets, and
• price (complete price including royalties and distribution charges),

See also

• List of PIGUI packages
• Graphical user interface

External links

• The old, outdated PIGUI FAQ
• The GUI Toolkit, Framework Page
• Lessons Learned from SUIT, the Simple User Interface Toolkit
• wyoGuide - tutorial on good cross-platform development