Gtk+ Generic Building (and some history ;)

[Tim Janik <timj gimp org>]

hello everybody,

i'll herewith try to put together the reasonings for the
gtk_widget_{set|get} mechanism and will extend on the default
constructors. i've made a short(?) historical excerpt because i
don't want to preclude Gtk newbies which tend to play a big rule
on gtk-list ;)

last years early january i started out on a project which was supposed
to build a graphical user interface (GUI) from a text file. i choosed Gtk
as a widget toolkit because it was completely free and superior in concerns
of flexibility and implementaion (doesn't use Xt) to other toolkits that i
had come across. when i started out on the first implementaion details
i quickly came across outstanding bugs and passed on patches to peter mattis.
he then made available his so far privatly kept code that implemented widget
signal emissions (object methods) and therefore allowed implementation
inheritance, which made him rename Gtk to Gtk+.
i then dropped the approach of parsing a text file and begun to work on GUBI
which enabled a user to modify the widget tree at runtime and would put out C
code for later compilation and creation of the widget tree.
meanwhile peter kindly made lots of changes to the toolkit's code which would
allow dynamic modifcations.
one thing that i spend a great deal on was to allow modification of certain
widget attributes, such as the border_width of containers. GUBI therefore
incorporates a lot of information about certain widget types in its code,
and it would rebuild the whole tree once any of these parameters had changed.
when peter mentioned to me he'd like to not see the tree to be rebuild upon
such changes, i recoded some parts to omit the rebuilding.
but some peaces still wouldn't allow modification without a full rebuild
of the tree, such as the order of children in a GtkBox (just recently i
implemented the functions that allow dynamic modification of a boxes
children, that is gtk_box_reorder_child, and gtk_box_set_child_packing).
so somewhen in the middle of may peter started work towards the gtk_widget_set
functionality.
since then it still hasn't been fully implemented for most of the widgets,
but the basic functionality is there now (again recent changes improved
that meachanism, e.g. a widget argument can now be applied and retrived,
and the toolkit actually makes a distinction between arguments that
are readable and/or writable). one thing that sprang out of this was the
widget = gtk_type_new (gtk_any_widget_get_type ()); functionality better
known as
widget = gtk_widget_new (gtk_any_widget_get_type (), NULL);
this is the same mechanism that allowes widgets to inherit from a certain
parent type, since inheritance needs to default construct the parent's
part of a widget structure. now some widgets take arguments in their
gtk_widget_new () function to layout the basic widgets functionality in
a certain way, e.g. the GtkTable used to operate on a fixed grid only which
will be supplied in the constructor. for the sake of inheritance (GtkTed),
miguel de icaza reimplemented the grid allocation code of GtkTables to deal
with subsequent changes, and therefore he made inheritance from GtkTable
possible.
there are other widgets that still introduce this problem and in favour
of preservation of the current constructer signatures, along with the
facility to have a fixed set of parameters that won't change during a widgets
lifetime, i'd like to have the GTK_ARG_CONSTRUCT functionality.
just recently (as stated in another mail) i had a discussion with jay painter
about dynamic changes to the number of columns in a GtkCList. since the whole
code is build on top of the assumtion that the count of columns is fixed,
it actually makes a lot of sense to preserve this assumption (the same applies
to the character grid size of a GtkTerm and probably does apply to other
widgets as well).
for GtkCList, jay moved the allocation code for columns out of gtk_clist_new ()
into gtk_clist_construct () and exported this function.
on the one hand, this allowes for generic widget creation like
widget = gtk_type_new (gtk_clist_get_type ());
but it involves the special magic, that gtk_clist_construct () needs to be
called after the construction. this is something a generic building interface
couldn't tell.
now my personal approach on a solution to this specific problem is to
export the functionality of gtk_clist_construct () (and likewise functions for
other widgets) through the gtk_widget_set () mechanism.
the specific argument GtkCList::columns will therefore be flagged in a special
way: GTK_ARG_CONSTRUCT.
GTK_ARG_CONSTRUCT implies that this argument needs to be set after the widgets
construction, is writable and can be applied only once.
the flags of a widget's argument can be queried via gtk_object_query_args (),
which will be done for generic interfaces after a widget has been created.

now if someone has a better solution for default construction along with
preserving fixed set arguments on a widget, i'll gladly think it over.

hope i didn't bore the majority of the audience on gtk-list ;)

---
ciaoTJ