
This directory contains several examples of how use DWI.
You should study the examples in the following order:

DWI XML Examples
----------------
These examples show how to hook up simple glade/dtk dialogs
to SQL database tables, using the dui XML language.  All of 
these examples are in the "basic-sql" directory.

testbasic -- The testbasic.dui file contains most of 
  basic DWI documentation.  Read this file first.  To
  run it and see what it does, you will first need to 
  create a database, and initialize it:
  
  If you're using Postgres, then run the following Postgres 
  commands at the shell prompt:

  $  createdb testbasic
  $  cat testbasic.sql |psql testbasic
  
  The default database driver (libdbi) does not require setup;
  but if you wish to use the ODBC driver, you will also need to 
  setup odbc to access this database; you can use the gODBCConfig 
  or ODBCConfig graphical clients to do this.

  Next, you will want to edit "testbasic.dui" to change
  the login name from "linas" to your database login name.
  Finally, you can run the example:
  
  $  ../../app/dwi-run testbasic.dui
  
  The next two examples should be treated the same way: you
  create the database, and then you run the GUI.

testlogin -- An example showing how to collect a database
  user login and password from a GUI dialog.  Uses the 
  same database and GUI as testbasic.

testwidgets -- Shows how to use over a dozen different 
  widgets, including menus, combo-boxes, sliders, etc.


DWI-to-GObject Examples
-----------------------
One does not have to use SQL at all to use DWI.  Generic,
non-SQL GUI applications can be developed by hooking up
glade dialogs to GLib Gobjects which do all of the actual
computations.  The "basic-gobj" directory contains some
examples showing this usage.

The "active-object" is the simplest such example.  The
demo GObject called "falling object", which takes
two inputs, and adds them together.  The "active-object.dui"
file defines how to hook up the object to the glade GUI.
The "active-object.c" file just contains main(), which 
just initializes gtk, glade and dwi.

To run the demo, just run "./active-object" at the command 
line.


DWI-to-GOB Example
------------------
Because the building of GObjects by hand is quite tedious, 
one might prefer to use "gob" (http://www.5z.com/jirka/gob.html)
to simplify the creation of GObjects.  The directory "bike-calc"
contains such an example.  It is a re-write of the old "calcalc"
Bicycle Ride Calorie Calculator from Greg Kondrasuk 
<kondrag@geocities.com>, which was written in FLTK and is at
http://www.geocities.com/SiliconValley/Vista/6434/calcalc.html

Part of the point of this example is to provide a slightly
more complex, 'real-world' example.   In part, the goal is
to see if it really is 'simpler' (as measured in terms of
lines of code) to develop with DWI as compared to C++. 
At the moment, it seems to be: the original 'calcalc' 
comes in at 1200 lines of C++ code (as measured with 'wc'), 
whereas the DWI re-write uses only 600 lines in the two gobs 
and the dwi file.

Run 'biker' to run this demo.


DWI-to-GTK Interopration Examples
---------------------------------
The following are "advanced" examples, and show how to 
integrate DWI functionality into a pre-existing GTK
application.   These examples do not need to be studied
unless you are planning on performing this kind of 
integration;  most basic data-driven applications
can be written entirely in DWI, without resorting to 
C code.  But if you must, here they are:

button-action.c -- simple example that causes a DWI
  form to be executed when a button is pressed.

view-entry.c -- a more complex example that shows
  how to run an 'arbitary' SQL query, and show the
  results in a DWI form.

Note: to run the above examples, you will have to 
  $  createdb testbasic
  $  cat testbasic.sql |psql testbasic

and you will need to edit "testbasic.dui" to change
the login name from "linas" to your database login name.


DWI-to-QOF Example
------------------
DWI can be used together with the QOF Object Framework.
The goal is to be able to "automatically" synchonize 
a QOF object to an SQL database, so that changes in one
are reflected in changes to the other. In particular, a 
goal is to keep these changes "transactional" 

The directory 'basic-qof' shows a crude prototype of some 
of the functions that might be expected in a future QOF
backend.  This directory contains a functional example, 
but you probably don't want to actually code this way; 
you probably want to wait for the 'real' QOF backend
that will make this much easier.

The staging area for the 'final' QOF DWI backend is 
in the 'qof-proto' directory.  It doesn't work yet.
It'll be hairy anc complex :(

================  THAT'S ALL FOLKS ================
