Code savers...

[Jeff Evarts <jdeassoc earthlink net>]

I had a couple of thoughts about saving some code.

1. My first suggestion aims at decreasing the amount of code
   in widgets in general.

   We could extend the gtk_object_add_arg_type() into a
   function gtk_object_add_simple_arg(), which would include
   an "offsetof" into the structure of the new object, and if
   that argument is updated, the GtkObjcet code will do
   the assignment by itself, rather than calling a function
   in the new object's code.

   The same could be done for set_child_arg functions as well.

   Remember, the current function would still be there, so if
   you WANT side effects, you can have them, but in most of
   the cases I've seen in the source code (or at least a lot
   of them) there aren't any side effects.

   Remember you can also mix and match. Some arguments may
   use the _simple_ functionality, while others will call
   back into your code.

   I suggest this because in browsing the simple containers,
   I see a massive amount of redundancy in the code where we
   come into this function only to hit a switch and some
   assignments, and this could all be done without our
   intervention if we extended the object.

   Pros:
	1. Over 150 (out of 784) lines saved in gtkbox alone
	2. lots less pointer dereferences and function calls
	3. Extends, does not replace current functionality
	4. You can even mix & match functionality if you
	   want side effects for just some arguments
   Cons:
	1. Expands the gtkobject code somewhat.

2. My next suggestion is to improve the code reuse and strength
   of the generic GtkContainer class.

   First, add an element to _GtkContainer called "sizeofchild".

   Second, "subclass" GList into "ContainerChild", adding a
   "widget" element:

	struct ContainerChild
	{
	  Glist glist;
	  GtkWidget *widget;
	};

   Third, default "sizeofchild" to sizeof(ContainerChild)

   Lastly, write container_add, container_remove, and
   container_search_for_widget functions, and use that code
   in subsequent objects

   Pros:
	0. The GtkContainer function could have a default
	   add function instead of the "unimplemented" garbage
	   it has now. Likewise remove and search
	1. one half of the allocations and deallocations
	   for each child added go away.
	2. no more child/children differentiations, no more
	   children->data... you just subclass GList.
	3. Fewer casts, fewer temporary variables.
   Cons:
	1. Couldn't think of any

Both of these changes fall into the "fairly major" category,
but both would shrink the overall size of the library, and
the resultant executable.

Both would also improve performance at the same time, while
leaving the current functionality completely unchanged.
(Unless you were trying to get the "unimplemented" message,
which cannot show up any more :-))

-Jeff
-- 
-Jeff Evarts
--jdeassoc@earthlink.net
---http://www.ecst.csuchico.edu/~amarth/