Platform-independent GUI library

<h2 id="considerations">Considerations</h2>
<p>Using a PIGUI has limitations, such as the PIGUI only deals with the GUI aspects of the program so the programmer responsible for other <a href="/facts/Software_portability/tWKVGCBb">portability issues</a>, most PIGUIs slow the <a href="/facts/Execution_(computers)/1fyfGMFm">execution</a> of the resulting code, and programmers are largely limited to the feature set provided by the PIGUI.
</p><p>Dependence on a PIGUI can lead to project difficulties since fewer people know how to code any specific PIGUI than do a platform-specific GUI, limiting the number of people who can give advanced help, and if the <a href="/facts/Vendor_(supply_chain)/NayQNfhq">vendor</a> goes out of business there may be no further support, including future OS enhancements, though availability of <a href="/facts/Source_code/o9J6Jv23">source code</a> can ease but not eliminate this problem. Also, <a href="/facts/Software_bug/I1uSXySv">bugs</a> in any package, including the PIGUI, filter down to production code.
</p>
<h2 id="alternative-approaches">Alternative approaches</h2>
<p class="note">See also: <a href="/facts/Rich_Internet_application/en12v9La">Rich Internet application</a></p>
<p><a href="/facts/Web_browsers/2pfyymLs">Web browsers</a> offer a convenient alternative for many applications. Web browsers utilize <a href="/facts/HTML/sSc3fT78">HTML</a> as a presentation layer for applications hosted on a central <a href="/facts/Server_(computing)/dEaYFD7r">server</a>, and web browsers are available for pretty much every platform. However, some applications do not lend themselves well to the web <a href="/facts/Paradigm/HXpK3X7a">paradigm</a>, requiring a local application with GUI capabilities. Where such applications must support multiple platforms, PIGUI can be more appropriate.
</p><p>Instead of using a PIGUI, developers could <a href="/facts/Model%25E2%2580%2593view%25E2%2580%2593controller/vRbMXjMm">partition</a> their applications into GUI and non-GUI objects, and implement the GUI objects in the native <a href="/facts/API/GMlN4vUr">API</a>. Then, when porting, only the GUI objects need to be rewritten for the new platform.  There are some <a href="/facts/Software_developers/WGTS1Jv9">software developers</a> who recommend this course of action, as it produces a better fit on each platform and eliminates the <a href="/facts/Computational_overhead/e2jgPrHr">overhead</a> 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, which is not (usually) a trivial task, hence the market for PIGUI packages.
</p>
<h2 id="user-interface-approaches">User interface approaches</h2>
<p>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.
</p><p>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 <a href="/facts/Look-and-feel/Uo3RcETT">look-and-feel</a> correct on all platforms.
</p><p>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 <a href="/facts/OpenWindows/xXKW1E6N">OpenWindows</a> support, the software would NOT produce an <a href="/facts/XView/Y7VvB08A">XView</a> program that must be compiled with the XView toolkit; the software would produce code that interfaces directly with <a href="/facts/X_Window_System/ac2vRIQL">X</a> 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 <a href="/facts/Apple_Macintosh/8GhnXTK0">Macintosh</a>-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 purchase of (or learn how to use) other packages to build GUI software.
</p><p>A third approach to platform independence is emulating one of the supported target's <a href="/facts/API/GMlN4vUr">APIs</a> (usually, the <a href="/facts/Windows_API/RRw4RtTu">Microsoft Windows API</a>) 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.
</p>
<h2 id="features">Features</h2>
<p>PIGUI packages are pretty similar in their basic functionality; they each provide <a href="/facts/Subroutines/9vFJrg0A">subroutines</a> or objects that allow the user to build <a href="/facts/Window_(computing)/g39X0vV3">windows</a>, <a href="/facts/Button_(computing)/TAJ36ebs">buttons</a> (regular as well as <a href="/facts/Radio_buttons/nmTS7VHF">radio buttons</a> and <a href="/facts/Check_box/r8K5WtoR">check boxes</a>), <a href="/facts/Menu_(computing)/zdKCgPGq">menus</a>, and the like. Some areas of differentiation are:
</p>
<ul><li>support for the platforms needed,</li>
<li>the choice of implementation <a href="/facts/Programming_language/cWTYbgWa">language</a>,</li>
<li>availability of source code,</li>
<li>support for printers and other devices,</li>
<li>support for various character encoding schemes including Unicode,</li>
<li>capability to support draw-package-like features,</li>
<li><a href="/facts/Bitmap/Fr80ySnT">bitmap</a> (and <a href="/facts/Icon_(computing)/habCR8KJ">icon</a>) support,</li>
<li>the <a href="/facts/PIGUI/ae8YNLmX">approach</a> to platform independence,</li>
<li>nifty high-level <a href="/facts/Widget_(computing)/SuVeScB2">widgets</a>, and</li>
<li>price (complete price including <a href="/facts/Royalties/8caVPHCP">royalties</a> and distribution charges),</li>
<li>some packages include features for rendering graphics, or handling vector graphics, which are useful for creating custom designs.</li></ul>
<h2 id="see-also">See also</h2>
<ul><li><a href="/facts/List_of_platform-independent_GUI_libraries/GKrp1VAT">List of platform-independent GUI libraries</a></li>
<li><a href="/facts/List_of_PIGUI_packages/GKrp1VAT">List of PIGUI packages</a></li>
<li><a href="/facts/Graphical_user_interface/wBlQFWDP">Graphical user interface</a></li></ul>
<h2 id="external-links">External links</h2>
<ul><li><a href="https://web.archive.org/web/20080816180726/http://www.zeta.org.au/~rosko/pigui.htm">The old, outdated PIGUI FAQ</a></li>
<li><a href="https://web.archive.org/web/20091026132520/http://geocities.com/SiliconValley/Vista/7184/guitool.html">The GUI Toolkit, Framework Page</a></li>
<li><a href="http://www.cs.virginia.edu/~techrep/index.html">Lessons Learned from SUIT, the Simple User Interface Toolkit</a></li>
<li><a href="http://wyoguide.sourceforge.net/">wyoGuide - tutorial on good cross-platform development</a></li>
<li><a href="https://ieeexplore.ieee.org/document/6871781">Platform independent GUI for reconfigurable ultrasonic system-an-chip hardware</a></li></ul>

Platform-independent GUI library open-in-new

Platform-independent GUI library