|Did you know ...||Search Documentation:|
|Why GUI-Builders are evil|
GUI-Builders are there to make the life of a programmer easier by reducing the learning curve, and let you create better applications faster. This page questions these claims.
GUI-Builders provide a GUI to specify a GUI. Below we summarise the technical requirements for designing and implementing a GUI.
A GUI-Builder provides lists of available controls, menus for configuring these controls and direct-manipulation editors for placing them on the window.
GUI-Builders provide a natural and appropriate mechanism to select and position a static configuration of controls in a window. If the window serves as a view for some model and the construction of this model fits the assumptions made in the GUI-Builder, it provides adequate mechanisms to link the application to the GUI.
Abstraction, rules for defining dynamic building as well as dynamic relations between components are tackled poorly by graphical interfaces, while these aspects have great influence on notably the maintainability of interface code.
The power of Prolog lies in its declarative nature and the ease to implement rules working on this representation. A well designed Prolog application is founded on a simple, easy-to-maintain Prolog fact-base. A well designed GUI implementation should exploit this foundation as much as possible.
Suppose we have several entities in our application with some properties. The GUI should be able to create, view and update instances of this entity. Using `modern' Object Oriented technology and a GUI builder, we would define classes to reflect each of the entities and use the GUI-Builder to design dialog windows for each of the entities. If we have a good GUI tool, we can associate these using a model-view relation and the communication will be set-up automatically.
This approach is not ideal. Suppose we will also add context help to the system. We end up with many locations where strongly related information is stored: the class-definitions stores the attribute-names and their types, the method-implementation encode constraints and relations in the data-model, the GUI-Builder defines the control-selection and layout and the help-file the associated text.
When using XPCE/Prolog we use a Prolog fact-base that describes all relevant information about the entities in a single location. We will use this information to maintain the database (either in Prolog, as XPCE objects or in an external database), evaluate constraints on the data, generate the dialog windows and provide (multilingual) context sensitive help.
This is feasible due to the meta-programming capabilities of Prolog and the strong support for symbolic layout management of XPCE.
The learning curve for designing applications this way is certainly longer. Once on steam however, you will see your productivity rise sky-high while your programs are clear and easy to maintain!