In this chapter you find the answer to the above question beginning from a short overview up to a description of the technical concept.
The idea of XGAP is that GAP should be able to control graphics. A graphical user interface is sometimes easier to use than a text and command oriented one and there are mathematical applications for which it can be quite useful to visualize objects with computer graphics.
On the other hand it is not sensible to change the whole concept and user interface of GAP because it is not advisable to put all the facilities of GAP into a menu system. So XGAP is a separate C program running under the X Window System, which starts up a GAP job and allows normal command execution within a window. Note that the online help of GAP is available, however it will appear in a separate window.
In addition there is a library written in GAP, which makes it possible to open new windows, display graphics, control menus and do other graphical user communication in GAP via the separate C part.
Built on those ``simple'' windows and graphic objects are other libraries which display graphs and posets in a window and allow the user to move vertices around, select them and invoke GAP functions on mathematical objects which belong to the graphic objects.
One ``application'' of these libraries is a program to display subgroup lattices interactively. So XGAP works as a front end for mathematical operations on subgroup lattices. It is possible to ``switch'' between the graphics and the GAP commands. This means that you can for example use the graphically selected vertices resp. subgroups to do your own calculations in the command window. You can then display your results again as vertices in the lattice.
Of course there are other applications possible and the libraries are developed with code reusage in mind.
XGAP graphic sheets work graphic object oriented. This means that the basic graphic objects are not pixels but lines, rectangles, circles and so on. Although technically everything on the screen consists of pixels XGAP remembers the structure of your graphics via higher objects. This has advantages as well as disadvantages. Do not expect to be able to place pixel images into your XGAP graphic sheets. That is as of now not possible with XGAP and probably will never be, because it is not the idea of the design.
What you can do is create, move around and change lines, circles, text and so forth in graphic sheets. Your programs can communicate with the user via graphical user interfaces like mouse, menus, dialogs, and so on.
It is very easy to link this graphical environment with your programs in the mathematical environment of GAP. So you can very quickly implement visualizations of the mathematical objects you study. The user can select objects, choose functions from menus and ask for more information with a few mouse clicks.
A good example for this approach is the implementation of the interactive Todd-Coxeter-Algorithm to compute coset tables in finitely presented groups. It uses the graphical features of XGAP to give the user quick and easy access to the algorithm by a few mouse clicks. This program was written by Ludger Hippe in Aachen using XGAP3 and is currently ported to XGAP4 and extended by Volkmar Felsch.
Another nice little example is in the examples subdirectory in the
XGAP distribution. It was written by Thomas Breuer (Aachen) to
demonstrate the features of XGAP. The user gets a small window with a
puzzle and can solve it using the mouse. You can test this example by
starting XGAP and Reading the file pkg/xgap/examples/puzzle.g.
You can do this by using
gap> ReadPackage("xgap","examples/puzzle.g");
gap> p := Puzzle(4,4);
You do not have to invent the wheel many times. For certain mathematical concepts like graphs, posets or lattices XGAP provides implementations which can be adapted to your special situation. You can use those parts of the code you like and substitute the other parts to adapt the behaviour of the user interface to your wishes.
XGAP consists of a C program xgap (in the following xgap in
typewriter style refers to this C part) separate from GAP, and of some
libraries written in the GAP language. xgap is started by the
user and launches a GAP job in the background. It then talks
to this GAP job. Especially it displays all the output which comes from
GAP in the communication window and feeds everything the user types in
this window into the GAP job.
But there is also some communication with the GAP job about the graphics
that should be displayed. Because GAP has no concept of putting graphics
on the screen, this part is done by xgap. Therefore there is a protocol
between the GAP part of XGAP running in the GAP session and xgap
which is embedded in the input/output stream. The user does not notice
this. xgap stores all windows and graphic objects and does all the work
necessary for displaying windows and managing user communication and so on.
The GAP part of XGAP also stores all graphical information, but in
form of GAP objects. The user can inspect all these structures and use
them in own programs. Changes in these structures are transmitted through
the communications protocol to xgap and are eventually displayed on the
screen. User actions like mouse clicks or keyboard events are caught by
xgap and transmitted to the GAP job via function calls that are
``typed in'' as if the user had typed them. So the library can work on them
and change the GAP objects accordingly.
Technically, XGAP is a package and one of the first commands that
is executed automatically within the GAP session is a
LoadPackage("xgap") call. This reads in the extra XGAP
libraries. They are found in the pkg/xgap/lib subdirectory, normally in the
main GAP directory. The files contain the following:
window.g
sheet.g[di]
color.g[di]
font.g[di]
menu.g[di]
gobject.g[di]
poset.g[di]
ilatgrp.g[di]
meataxe.g[di]
The user normally does not need to know this or the details of it. However,
it is important to understand that the program xgap is highly machine or
at least operating system dependent. There is no generic way to access
graphics across different platforms up to now. XGAP should run on all
variants of Unix with the X Window System Version 11 Release 5 or
higher. As of now XGAP does not run on Microsoft Windows. It is
also definitely not easily ported there, because some important features
that are used within XGAP are missing there (such as pseudo terminals).
There are currently no plans underways to do work in this direction.
A first program for drawing a diagram showing the lattice of subgroups of a finite group that had been calculated by a computer was implemented by H. Jürgensen in 1965 (see FJ65).
The design of XGAP was strongly influenced and in fact triggered by the QUOTPIC system of Derek Holt and Sarah Rees (see HR91) which allows to depict graphically knowledge about normal subgroups of a finitely presented group found by a variety of methods for the investigation of finitely presented groups. It seemed most desirable to allow to depict in a similar way the even wider variety of information on subgroups of groups that can be obtained by a system such as GAP.
Beginning 1993, Frank Celler developed the idea of an interface from GAP to graphic systems that allowed to actually write commands for graphical tasks in the GAP language and together with Susanne Keitemeier (see SK95) wrote a first version of programs in XGAP for drawing diagrams representing posets of subgroups of finite and finitely presented groups. We most gratefully acknowledge the help of Sarah Rees in implementing the interactive lattice functions and in beta testing the GAP3 version of XGAP.
In 1998, Thomas Breuer, Frank Celler, Joachim Neubüser and Max Neunhöffer planned the new concepts for the GAP4 version. The implementation and porting to GAP4 was done mainly by Max Neunhöffer in 1998 and 1999. Michael Ringe added the link to his MeatAxe programs. We like to thank all those who have adapted the GAP library to the needs of the new XGAP, in particular Alexander Hulpke who has been extremely helpful with this task.
[Up] [Previous] [Next] [Index]
XGAP manual