DWI is a data-driven application designer for Gnome.
It doesn't matter if your development platform is the web and Enterprise Java Beans, C# and .net or Mono, or whether its the Gnome/GTK or KDE widget set and the Linux desktop; its still just plain hard.
DWI is an effort to change this situation. DWI currently offers a simple way of developing data-driven (that is, SQL-backed) Gnome applications (designed with the Glade GUI designer).
It does this by avoiding "programming" (or at least, "traditional programming" in C. C#, perl, python or any other "traditional" language), substituting instead a configuration-file like format that defines how various GUI elements should be hooked up to various objects (such as GLib GObjects) or SQL fields and tables.
The current primary effort with DWI is to provide a number of well-documented, easy-to-understand, working examples that show how to use DWI. These examples currently include a stand-alone bug-tracker-like application, examples of integrating with existing GTK applications, and an example of hooking up a Glade-designed interface to a GLib GObject with almost no C programming at all (assuming you have a GLib GObject already handy.
DWI 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 has enough features to be adequate for creating form-editing and reporting applications. Multiple SQL database vendors are supported through ODBC or libdbi drivers. There is a simple db-driver infrastructure so its easy to support for additional SQL API's. The system supports all of the basic Gtk widgets, and an additional half-dozen Gnome I/O widgets, such as GnomeDateEntry.
DWI is powered by an 'engine' that has some fairly generic procedures for mapping 'fields', such as SQL table columns or widget values, between each other, and also between other things, such as objects, hash tables and etc. In a certain sense, the engine can be thought of as an Object-to-Relational Mapping (ORM), mapping SQL to several object systems, including Glib GObjects and QOF. This engine has been designed so that it becomes easy to add support for all kinds of new object systems: i.e. for the engine to be a generic re-mapper between not just SQL and GTK but between many different types of object systems and data sources/sinks.
Built on top of this engine is a DWI application that parses an XML-based file, the "DWI file", that describes the connections between glade widgets (or objects in general) and database tables. Currently, the only way to create DWI files is by hand. Unfortunately, this can be a fairly long and laborious process itself, especially when creating 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. (Work has begun on such a tool, written in DWI itself).
The grim reality is that DWI won't ever become popular without a graphical designer. Although fairly complex apps can be readily created using DWI, it does have a non-trivial learning curve. When we say "can be created quickly", we mean "days" or "weeks", as opposed to "months" for traditional database application development cycles. Graphical RAD tools have a way of being brainlessly pleasant to use, and give the impression of an even faster development cycle, even though the learning curve is identical.
Note that the design of the XML format is sufficiently generic that it is not directly tied to Glade. It should be straightforward to adopt other ORM markups to inter-operate with the DWI engine. It is also envisioned that other GUI object systems, such as PHP, could be used with DWI, so as 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.
What's New in This Release:
· Changed to use automake Makefile system for easier installs; 'make install' target now works.
· Segregate gtk and qof features to own subdirectories, so that apps which do not nead gtk do not need to link to the gtk libraries.
· Add support for QOF objects, including multiple examples of using QOF.
· Finish modularize of the SQL db drivers, so that only the required driver is actually loaded.