Steve wrote:
>
> Looking for some advice on what I want to do with glade :
>
> My requirements are as follows :
> - I am creating database apps, where I am using postgreSQL / or mySQL
> - I dont want dependencies on libgda, or any other leading edge gnome
> stuff - plain plain old gtk apps with raw interfaces to the database,
> that work on any linux platform that supports GTK
> - The screens / forms follow a common theme. That is, there might be
> 200+ forms in an application, but all forms are derived from some basic
> type with common behaviour. The types identified so far include :
> - Login screen
> - Selection screen - displays a set of records in a clist, click on
> one and it takes you to another form.
> - Record maint form - displays all the fields for a particular
> record, with the ability to update the record
> - Table browser - displays a list of records in a clist, click on one
> and the record details are displayed on the same form.
> Can insert / delete / modify records from here
> - Order entry form - uses some input fields and an embedded gtksheet
> for a typical order entry
>
> Each of the 200+ forms are very different, but they all basically fall
> into one of the above catagories.
> The forms are in fact containers, not top level windows, so they can be
> embedded in a notebook, or a table, etc.
>
> ----------------
> Alternate approaches to acheiving the above using glade :
>
> 1) Create a set of mega-widgets as raw GTk widgets, one for each type of
> form, and embed these into the glade palette.
I like this option the least. You'd have to use your own customized version
of Glade, writing new widgets is quite tricky, and you'd still have the
problem of creating sub-types.
> 2) Add a scripting plugin to glade, so that the executing script simply
> applies a number of operations to build up a form using standard gtk
> widgets.
This sounds like quite a bit of work and I can't see any advantage over
option (3) which is much easier to do.
> 3) Write an external program that simply generates a big pile of
> XML that can then be loaded into glade.
This sounds the best of the 3 options. It may even be better if you put
each form in a separate XML file and use libglade to load & create them.
Using libglade you can easily add a function to remove the form from its
toplevel window automatically, so you can place it in notebooks etc.
> Most of the callback code for each form would be common, and easily
> generatable given that you know what the behaviour of the form is, and
> what data elements are being updated or otherwise acted upon in that
> form.
I'd suggest another option:
4) Create the forms dynamically inside your application - i.e. don't use
Glade at all!
You could use a separate form-creation function for each main type and
pass extra data about the specific interface elements needed.
This is what I'd be tempted to do, though I don't know your requirements
exactly.
Damon
_______________________________________________
Glade-devel maillist - [EMAIL PROTECTED]
http://lists.helixcode.com/mailman/listinfo/glade-devel
