This document assumes a reader who is an experienced, while not expert, GUI programmer. Since the toolkit I am most familliar with is Gtk, I will use it as an example throughout. Obviously, some knowledge of XML is required, as this library relies entirely on XML documents. Knowledge of Xerces, the Apache XML parsing library used to drive Azure, is not required, either to use this library, or to make documents for it. Xerces is only important to anyone who would wish to extend or enhance Azure. More specifically, experience with a DOM API is required, for while Xerces provides SAX and DOM (two XML API's), Azure uses the DOM exclusivly.
As an armchair GUI hacker, I get tired of writing GUI code. Making GUI code at a low level is complex and difficult, and the this increases exponentially with the complexety of the application. This complexety has several causes and ramifications. The chief cause is the tendency of GUI toolkit designers have of making the programmer know too much about the internals of the toolkit they use. Various toolkits do this to varrying degrees, but there is another, more fundamental cause. This other cause is unavoidable, regardless of the best efforts of the of the toolkit designers. Toolkits are complex because they are a procedural interface for describing an abstract concept.
All toolkits are simmilar in one respect, in order to create a GUI, a programmer has to define the steps that will create the GUI, usually in C, C++, or Java. Azure takes a different approach. Since Azure is in part an XML grammar, it is inherently declarative. A Azure source file is a description of a GUI, much the way HTML is a description of the Web page that a browser generates. A Gtk+ source file, on the other hand, would consist of the steps the toolkit should take to create the GUI. For most common GUI components (or widgets), it is possible to make a collection of one or more source files, and a separate set of one or more Azure source files that describe a GUI. Some may prefer the procedural approach, but I feel that most people would take to the declarative approach.
Since most GUIs are written in some form of procedural language, a legitimate question arises: What is so bad about using a procedural language to generate a GUI? First, in response, I'll mention some good properties of procedural language toolkits. First and foremost, they make more types of applications possible, by exposing more layers of the system. While Azure only exposes the highest level of the system, dealing with buttons and windows, most toolkits expose everything down to primitve drawing routines. These routines let programmers make thier own widgets, and allow extended functionality, like video playback. Also, they are faster. Since no toolkit has to go through the extra steps of parsing and interpreting an XML file, procedurally defined GUIs will run faster. So, in response to the hypothetical question I posed my self, what is bad about procedural toolkits is what is good about Azure. Azure is toolkit neutral, so knowledge of the fine details of any toolkit is not required. A higher lavel view of the application's GUI is also afforded by Azure, since it hides the implementation details of it's toolkit. A procedural toolkit carries a steep learning curve around with it. It also has programming skill as a prerequisite. Since the GUI can be described declaratively, and programming skill is not trivial to obtain, whole legions of non-programmers are locked away from GUI design. Finally, procedural GUI creation is tied to one application, and one host language. There is no standard widget library, with systems like Azure, there is a future for generic GUI programming.
So, in summary, the power of procedural programming tools is not required for the majority of GUI programs. This majority can be served by a declarative system in lieu of full blown procedural programming, even with a well designed GUI toolkit. The declarative approach is more natural, and it is also accessable to non-programmars. This lets programmars focus on more important things, like rewriting linked list libraries.
Azure offers a number of attractive features to a progammers's arsenal. At the same time, it does in in a toolkit neutral, platform agnostic way, so the application is as portable as the programmer wishes to make it. Here are some of the features of Azure:
Imagine that an application calls for a window entitled "Hello, World!". This window contains a button with the label "OK". For this example, this window is the entire GUI for the program.
Here is the Azure source code to make the window:
<?xml version="1.0"?>
<!DOCTYPE gui SYSTEM "gui.dtd">
<gui name="hello world" app="hello.c">
<window title="Hello, World!">
<button>
<label>OK</label>
</button>
</window>
</gui>
Here is the same code, expressed in C, using the Gtk toolkit:
#include <gtk/gtk.h>
main(int argc, char **argv) {
GtkWidget *window, *button, *label;
gtk_init(&argc, &argv);
window=gtk_window_new(GTK_WINDOW_TOPLEVEL);
gtk_window_set_title(GTK_WINDOW(window), "Hello, World!");
gtk_widget_show(window);
button=gtk_button_new();
gtk_widget_show(button);
label=gtk_label_new("OK");
gtk_container_add(GTK_CONTAINER(button), label);
gtk_widget_show(label);
gtk_main();
}
As you can see, the structure of the GUI is the same as the structure of the XML document. Just as the window tag is the parent of the button tag, so is the window widget the parent of the button widget.