This document is intended to provide an overview of the possibilities for an Allegro 5 GUI add-on. The add-on would be the "official" one shipped with Allegro, and used in any tools or examples using a GUI. Generally speaking, the more greens there are in the table the less work we would need to do to use the GUI in a5, and the better it would be. Writing our own GUI we could get all green, but it would take too long.
The table below compares each GUI over a range of features. To add a GUI or feature which is not in the table below, email me. A description of each feature is given below the table; click on a feature name to visit its definition, and click on a GUI name to visit its homepage. Note that some of these GUIs are still under very active development and their status may change. This is fine as a5 will not be released for a long time to come.
| GUI | C | Appearance | Buffer | Extensible | Arb. Obj | Metadata | Multi-dialog | Threads | Notes |
|---|---|---|---|---|---|---|---|---|---|
| Allegro 4 | Yes | Limited | None | Yes | Yes | Inflexible | No | No | Already shipped with a4. Known to be limited. |
| LW GUI | C99 | Color change | Any | Yes | Yes | Yes | Yes | Yes | Very object oriented, based on a4. |
| DIME | Yes | Limited | None | No | Yes | Inflexible | No | No | Sits on top of a4. |
| MASkinG | C++ | Skinnable | Library | Yes | Yes | Yes | Yes | Difficult | Uses alfont library. Very sophisticated. |
Gives the name of the GUI system under consideration. Click on the GUI name to visit its website.
Lists whether or not the GUI system is written in pure C. Systems limited to one compiler or platform get amber; systems written in other languages get red.
Gives information about how easy it is to customise the appearance of the GUI objects, and the GUI in general.
Describes the buffering system the GUI uses. Systems which draw straight onto the screen get a red; systems which use built-in double buffering get amber, and systems which can use any user- supplied system get green.
This field shows how easy it is to add to the GUI (new widgets and new behaviours).
Describes the system's support for adding arbitrary objects (widgets): systems which can support any new type of object the user designs get green, systems in which it is difficult get amber, and systems in which it is not satisfactory get red.
Lists whether or not the system supports per-object metadata (ie. arbitrary user-supplied information about the object).
Describes support for multiple dialogs. Systems which cannot support multiple dialogs (ie. because they use static data) get red, systems in which it is difficult (ie. because you must use threads or similar) get amber, systems which have explicit support for it get green.
Describes how easy it is to use in a multithreaded environment. To get an amber, the system must be totally based on objects with no significant static data. To get a green the system must be stateless and possibly provide mutexes where appropriate.
Further pertinent information.