This is a fairly simple environment for quickly creating data-driven applications, that is, graphical applications that manipulate and show info from a database. This environment differs from others in that it is focused on native GTK/Gnome support through the Glade GUI designer, and thus allows you to build user interfaces as elegant as you can make them in Glade.
At this point, this system is not feature-rich, but it should be adequate for creating basic form-editing and reporting applications. Multiple SQL databases are supported through an ODBC driver. It should not be hard to add a native Postgres driver, or even a non-SQL database driver.
The actual connection between the database fields and the glade widgets is described in an XML-based "DWI" file. Currently, the only way to create DWI files is by hand. Unfortunately, this can be a fairly long and laborious process itself, especially when creatting something a bit more sophisticated. In the future, we hope to have an extension to Glade, or possibly an extension to a database-browsing tool that will allow you to graphically make such connections. (Such a tool written in DWI itself, has been begun).
Note that the design of the XML format is sufficiently generic that it is not directly tied to Glade. It is envisioned that it could be used to create data-driven web pages. That is, Glade is currently the only GUI driver, but other drivers for other GUI's should be possible.
These screenshots show a very basic app. The screenshots are not of DWI itself, but of a very simple application created with it. Actually, what is shown was created by Glade; you'll have to take my word that there's a database behind this. Of course, depending on your glade skills, you can get much much fancier than this.
Here's a screenshot of DWI using the columned-tree widget. Again, not much point to this, other than to show that DWI does support displaying the results of SQL queries as columned trees (which can be tricky).
To create a DWI application, you need to know SQL, and you need to be able to write XML files, such as this one. You do not need to program in C or any other language. The dwi-run interpreter will run the entire application based on the DWI file.
A graphical editor, to create these XML files, is being developed; its curretly in the pre-pre-pre-alpha stage. Its being written in DWI itself, and so should prove that DWI can handle 'real-world' apps.
The HINTS file provides some HOWTO-type suggestions for implementing application features, and should give you a hint of what is possible in DWI.
Downloads are here. The current version is 0.2.1. It works; we could call it 1.0, but more is planned.
Note that the DWI design is fundamentally "declarative"; i.e. it works like a declarative language (e.g. Mercury). The nature of the interface is declared in the XML file. The "run-dwi" evaluator reads in this static file, sets up structures that correspond to the XML declaration. Then the evaluator goes into the main loop, and signals and events make everything happens according to the pre-determined definitions in the XML file. There is no run-time interpretation. There is no 'just-in-time' compilation. It just runs along the fixed paths, where each path had been pre-defined in the XML file, and each run-through is initiated by the user clicking or typing in the GUI.
A DWI application consists of one or more <database> sections, each of which consists of one or more <window> sections. The application windows themselves interact with the user as a <report>, displaying data, and/or as a <form>, collecting user input. Here is an example file.
A DWI application contains a rudimentary mechanism for handling application state: a global set of key-value pairs (implemented as a hash table). You can create a key-value pair at any time, and later use the values in database queries or in reports. Simple applications will typically not need to maintain state; more complex applications will typically use global state to map tree-like/heirarchical structures into the database.
Whenever a value is obtained from a widget, with the intent of putting it into the database, or from the database, with the intent of putting it in a widget, it can be passed through one of a set of pre-defined "filters". Only a minimal set of filters have been defined so far; more will be added.
The currently supported widget set is GtkEntry, GtkLabel, GtkText, GtkRadioButton, GtkFileSelection, GtkCList and GtkCTree. The GtkCList ("columned list") widget is a basic, simple table, and is 'automatically' filled by DWI. The GtkCTree widget is a heirarchical columned tree; its a bit harder to fill out, but it does support the filling of individual nodes with different database queries.
Currently, DWI ignores data types, and treats everythings as a string. This may change in the future. Since SQL database table definitions are typed, there is a natural pressure to put this kind of typing into schema designers and the higher level app (such as MS Access). So far, however, there seems to be no particular need for typing within DWI.