On Sun, Nov 25, 2001 at 10:59:54AM -0500, Derek Atkins was heard to remark:
> Basically, I'm stuck right now. I'm really at a loss for how to move
> forward and a) get something coded, but b) keep the process flexible.
> Clearly the process needs to be "scriptable", but I'm seriously at a
> loss for what the building blocks of the process should look like, or
> how to code the UI to match.
OK,
The following is a very very half-baked writeup, starting at square 1,
dashed off between interruptions. Its very simplistic, possibly too
simplistic; but maybe it'll give us a vocabulary to start with,
so we can move on to the hard conversations.
I'm going to put the object definitions in ascii files. The actual
format will be scheme forms or xml or something, but for right now,
I will just use space-delimited.
# this is a comment card.
# the following is a pretend address
BEGIN OBJECT "Address"
FIELD "Surname" STR
FIELD "City" STR
FIELD "Zip" STR
END OBJECT
BEGIN OBJECT "Order"
FIELD "Shipto" "Address"
FIELD "Amount" NUMERIC
END OBJECT
First note that this is purely declarative; nothing functional,
nothing algorithmic, no lambdas. It just declares types.
(Maybe Tyson Dowd could tell us how to best build a declarative
file format...)
This looks sort-of looks like SQL structs, except that I can use a type
after declaring it.
So much for the easy part. The hard part:
1) how to turn this into something that will hold data?
2) what are the programming API's?
3) how to attach this to the GUI?
Lets start with the api's. The basic api is a set of object and
field iterators:
char * get_next_object(); // first time its called, returns "Address"
// the second time it returns "Order"
char * get_next_field (char * obj_name);
// so that
// get_next_field("Adress") returns "surname"
// get_next_field("Adress") returns "city"
char * get_field_type ("City"); returns "STR"
-----------------------------------------------------
Lets move on to GUI's. There are multiple choices.
The ugliest gui would be to just display the output of the iterators,
with one object per window.
while (1) {
field_name = get_next_field ("Address");
field_type = get_field_type (field_name);
GtkWidget *label = gtk_label_new (field_name);
switch (field_type) {
case "STR":
GtkWidget *entry = gtk_text_entry_new ();
case "ENUM":
GtkWidget *entry = gtk_radio_button_new ();
}
gtk_table_insert_row (++row_num, label, entry);
}
We could make this GUI slightly pretttier by introducing a suggested
widget type for each field. Thus, while the datatype of "city" might
be "str", the widget type of "city" might be one of "text", "text_area"
or "label". But now we are on a slippery slope: its tempting to add
suggested dimensions to the "text_area"; before long we are putting
all sorts of gui formatting hints into the config file. That's bad.
A better GUI would be to tell the config-admin (the person creating
the config-file) to use Glade. Each glade can have a name. Those
glade widgets whose names correspond to a field name in the object
will get that fields value poked into it.
The glade approach will result in a nicer gui, and also potentially
allow several objects to be displayed in one window. Thus the glade
dialog might display:
/Order/Shipto/Surname
/Order/Shipto/City
/Order/Shipto/Zip
/Order/Amount
The upside is a nice gui, the downside is that creating a new gui
requires the use of glade.
Note: if we wanted to be really cute and clever, we could get the config
info out of the glade file. For instance, if the glade file had a
widget named
/Order/Shipto/Country&type=STR
we could deduce that the "Address" object should contain a field called
"Country" of type "str". (It might even be possible to wrte a glade
extension to provide more support for this, directly).
Clearly, there are a number of issues at the next level of detail,
but assuming these are solvable, waht other major issues are there?
Do you beleive a scheme like this would this work for the GUI component?
Should we proceed to the next level of detail?
---------------
Let me defer the storage/sql questions till later.
--linas
--
pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
