Design Considerations... Description versus Types...

[Suboner aol com]

As another addition to my previous post, I think its important to note the 
diffrence from widget descriptions and widget types. Currently in Gtk+ and 
other libraries there are some widgets that are not really widgets, but are a 
description of widgets. For example Glade and GLE want to have editing 
widgets, that are actually a combination and connection of other widgets. 
Another example is in the Gtk+ itself, a fileselectiondialog is actually a 
combination of widgets. The other option for these kinds of widgets is to 
create them externally as files, like having an xml file that stores common 
dialogs like fileselection, or external dialogs for manipulating other 
widgets, all that is really needed is the relational information, like the 
connection functions.

This is a sort of touchy situation because its easy to go either direction in 
extreme, either every object that is created is simply a description of other 
objects, or even GtkWidgets themselves can be broken down from being a 
description of data and data relationships. The best way to solve this 
problem is to have and follow a guide line of what a GtkWidget really is and 
what it is not, it is very easy, extremely easy for the idea of what a 
GtkWidget is to be lost, or to be generalized until GtkWidget can be just 
about anything anyone wants it to be. And even in the reference guide to Gtk+ 
1.2, there is lacking of a description of what a GtkWidget is. Maybe what is 
needed is to seperate this out a bit more, to have GtkWidgets be basic 
components of input (mouse) and/or ouput (graphics), and for things like 
GtkFileSelectionDialog be placed under another kind of object GtkTemplate, or 
GtkDescription, or what ever the Gtk authors thinks best, these templates 
could then be saved and loaded as files, and could be stored in a shared 
directory of other templates, of which users can specify default templates 
used for file selection, editing, and anything else they want to, this could 
be a part of themeability. An application itself can be treated as or 
inherited from a template because an application simply creates and connects 
objects. In general an template application will create new objects/GObjects 
and create new connection functions, the template application will then use 
them.