SWI-Prolog itself has no graphical capabilities and will not get them to ensure the system can easily be embedded in any type of application. We use SWI-Prolog primarily to develop interactive graphical applications. What are the alternatives?
- Direct access to graphical API
- Traditionally, people in the Prolog community have written Prolog wrappers around the native (C) API of their system. Xwip is an important example of this class of GUI approach for Prolog. Problem is that most of these API's are fairly low-level and a lot of work is required to get the data types of the API properly and naturally represented in Prolog.
- External GUI language
- A better and more popular approach is to use an external language designed for GUI development. Popular candidates are Tk/Tcl, JPL/Java, Visual Basic and Delphi. Prolog is connected to these systems using pipes, embedding or other suitable communication mechanisms.
- Using XPCE
- XPCE has been developed for GUI development in Prolog from the start. XPCE has a dynamically typed object-oriented kernel. Methods can be defined in any language. XPCE predefines a large number of classes, aiming at data-representation as well as graphics. The graphical library allows for abstract description of interface components and is portable to Win32 and Unix/X11.
Using XPCE, interactive Prolog applications can be written completely in Prolog. XPCE can be used for (space-)efficient storage of objects and object-oriented structuring of your application. As of XPCE-5, native Prolog-data can be passed and stored with XPCE/Prolog defined classes.