This posting is intended to shell-out as much information as I can find concerning platform-independent Graphical User Interface (PIGUI) development kits (actually, it's platform-independent APIs targeting various platform-DEPENDENT GUIs, but let's not get too picky). This list is being posted because I've seen a whole mess of requests for GUI portability information and, besides, I need this information as well.
This document is maintained and periodically updated as a service to the net by Wade Guthrie (wadeg@realm.net, or wade@nb.rockwell.com). Any corrections, updates, or other pertinent information are welcomed at that address. If you are a vendor of a PIGUI package (whether it's represented here or not), I encourage you to amend, annotate, and append to this document (and then, of course, send the revisions back to the author).
You can get the latest version of this FAQ (and, in fact, all the FAQs that appear in <whatever>.answers) *FREE-OF-CHARGE* by anonymous FTP from 'rtfm.mit.edu'. This FAQ can be found in the following directory: /pub/usenet/comp.windows.misc.
There are several mail servers that will do the FTP for you if you do not have access to FTP directly.
A PIGUI toolkit is a software library that a programmer uses to produce GUI code for multiple computer systems. The toolkit presents functions and/or objects (along with a programming approach) which is independent of which GUI the programmer is targeting. For the purposes of *this* document, a PIGUI must support the native look-and-feel for GUIs under at least two different operating systems (so just supporting OpenLook and Motif on two Unix boxes doesn't count). The toolkit does not necessarily provide any additional portability features.
Now, let's consider Petula Sniggly, a programmer who decides she wants to build the ultimate computer program. This thing is going to be so cool that everyone anywhere near a CPU will want to use it, so Petula targets her program for every type of computer on the planet. She considers getting herself a PIGUI toolkit to handle the GUI portion of her code. With a PIGUI toolkit, when she wants to put a menu on the screen, she calls the toolkit's "PIGUI_menu" function. When she compiles her code with the "Macintosh" flag set, the PIGUI library puts a Mac menu on the screen in response to the PIGUI_menu call. When she compiles her code with the "Motif" flag set, the call causes the library to put-up a Motif-style menu. All this happens (theoretically) without Petula having to change her source code. If she is careful to make her non-GUI code portable, she would have a single program (with a single source) that works on multiple platforms.
There is no free lunch, so our heroine Petula has a few things to consider before deciding whether to use a PIGUI. First, most (and maybe 'all' depending on whom you believe) of the PIGUIs will slow the execution of your code. You are also limited to the feature set provided by the PIGUI unless you want to code around the toolkit (but, then again, why would you buy the PIGUI in the first place if you're going to code around it?). Bugs in any toolset (PIGUI or otherwise) filter down to your production code. Fewer people know how to code any specific PIGUI than do a platform-specific GUI (e.g., MS-Windows), so wizardly help will be limited. The PIGUI only deals with the GUI aspects of your program -- you're on your own for other portability issues. Finally, if the vendor goes out of business you may be out-of-luck for support of future OS enhancements (source code can ease, but not eliminate, the pain of a vendor closing its doors).
Many C programmers will look at the purchase of a PIGUI library 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 his code to take advantage of) classes, inheritance, and constructors in order to complete the port. Of course, if one wants his C code to become C++ code, this is a necessary exercise anyway.
After the introductory stuff, you'll find some more detailed information about PIGUIs in general followed by tables and prose that describe specific PIGUI toolkits. The limits placed on which products are discussed in this posting are pretty-much provided in the title. The products listed here must be platform-independent and support at least two different OSs. The product must be shipping to the general public (i.e., no beta-only or pre-beta PIGUIs). Moreover, these packages focus on GUI portability, though some provide a larger breadth of portability features (and, I've tried to list those, where applicable). No limits (at either the high or the low end) have been placed on price, even though the prices in the field vary by more than an order of magnitude (and, now, there are some free PIGUI kits).
Note that in addition to one of the products listed here, you'll need (natch) one of the supported host machines, a compiler or interpreter of the appropriate type, and, for layered GUI packages (q.v.), the basic GUI builder for that platform.
At this point, I find it necessary (even though this is covered by my .sig) to say that this FAQ is my personal work and that this FAQ does *IN NO WAY* indicate, reveal, imply, infer, allude to, display, suggest, symbolize, expose, demonstrate, hint at, or in any way have anything to do with the thoughts, policies, suggestions, reflections, decisions, theories, sentiments, ponderings, rules, dreams, or beliefs of my employer.
I use a lot of names that are trademarks in this FAQ. At no time should the use of a trademarked name be construed as contesting the trademark. Those trademarks belong to their respective trademark holders.
If lots of stuff in this posting looks familiar to you, you're not hallucinating (well, maybe you are, but not regarding this). Much of the format (and some of the words) of this FAQ have been lifted (with permission -- thanks Eric) from Eric Raymond's PC-UNIX FAQ.