==== TO DO =====
- Support introspection, if/when it arrives

Adding support for extending GObjects
----------

In/Out issues:
- GtkEditable (insert_text/do_insert_text)
  -- this also affects the insert-text signal, so this is a good way around that
- GtkTreeModel (iter_next)

Some current issues/bugs with RGtk2
----------

Stuff that can wait for introspection
-------------------------------------
- these functions SHOULD free a string parameter by ref: (but they don't)
	pango_parse_markup, gtk_im_context_get_(preedit_string/surrounding), gtk_widget_(class)_path
- gtk_image_get_icon_set doesn't own the icon set but thinks it does
- PangoGlyphString: can only get first glyph from 'glyphs' array
- perhaps we should make sure we 'own' boxed types in signal callbacks
- pango likes to add fields to structures - would require versioning on fields
- field setting

Low Priority Issues
---------

- atkStreamableContentGetStream: need to map GIOChannel to R connection - not doable right now
- support translation of messages
- Returning *Funcs to R
- GtkRcPropertyParser - can we return the GValue by ref?
- allow specification of numeric precision on GtkCellRendererText
- could use new namespaced .Call mechanism (dll$foo) - better if cached
- GTypeModule support (create bindings and add module arg to gClass)
- R wrappers for callbacks so that return values are coerced

Introspection?
----------------
`-> Syntax tricks like the '$' and '[' operators could allow us to bind to 
	  methods and fields at runtime
	  `-> What about constructors? There's gObjectNew...
	  `-> What about ordinary functions - relatively few in number, 
		    could be explicitly bound at runtime
`-> Verdict: compiled bindings will always be faster, so for often used libraries,
    there should be a set of generated bindings. Other libraries can be bound
    on the fly with introspection. Introspection could help even in the compiled
    case. For example, parent handlers for virtuals could be invoked dynamically.
`-> Introspection could even be useful beyond convenient R<->C bindings - 
    other languages with GObject bindings could provide new types - no C needed -
    this means GObject would become a common language runtime.
    `-> But could this compete with virtual machine runtimes like Java and .NET?
    
Unsupported funcs
-----------------
Use the following code, with RGtk2 and your favorite "defs" loaded to find undefined
R functions:

invisible(sapply(names(defs$functions), function(name) { rName <- toCapPhraseName(name, TRUE, names(defs$objects)); if (!exists(rName)) print(rName) }))

[2] "gtkAccelGroupQuery"
[3] "gtkCListSetCompareFunc"
[1] "gtkContainerChildSetValist"
[1] "gtkContainerChildGetValist"
[3] "gtkCTreeSetDragCompareFunc"
[2] "gtkItemFactoryCreateMenuEntries"
[1] "gtkListStoreSetValist"
[3] "gtkSettingsInstallPropertyParser"
[1] "gtkTreeModelGetValist"
[1] "gtkTreeStoreSetValist"
[2] "gtkWidgetDestroyed"
[3] "gtkWidgetClassInstallStylePropertyParser"
[1] "gtkWidgetStyleGetValist"
[2] "gdkDisplaySetPointerHooks"
[2] "gdkDeviceFreeHistory"
[3] "gdkSetPointerHooks"
[3] "atkComponentAddFocusHandler"
[3] "atkObjectConnectPropertyChangeHandler"
[3] "atkAddFocusTracker"
[2] "atkFocusTrackerInit"
[3] "atkAddGlobalEventListener"
[2] "pangoFontDescriptionsFree"
[2] "pangoFontMapGetShapeEngineType"
[2] "pangoFontsetSimpleAppend"
[2] "pangoFontsetSimpleSize"
[2] "pangoReorderItems"

These 25 functions fall into 3 categories:
1) va_list (6): RGtk2 has no use for the functions taking va_list. Never supported.
2) undocumented/extremely low-level (10): The R programmer should not need these things. Never supported.
3) callbacks sans user data (9): need to record callbacks in an attribute on the R object then have
	one closure that calls the rest or if the callback scope is a function call something similar
	could be done as long as the calls aren't nested... May be supported, but probably not.
  See the dynamic variables package by Luke Tierney for possible solution.
	
Problems with defs files (as provided by pygtk)
--------------------
- GtkFileInfo/GtkFileSystem etc are not public
- gtk_init_abi_* is not part of the public api
- gtk_ctree_base_nodes has been removed from gtk
- gtk_icon_view_new_with_model should be marked as constructor
- gdk_color_new, gdk_rectangle_new, gdk_pixbuf_new_from_array are not actual functions
- In my opinion, gdk_atom_name is a function not a method, GdkAtom is not an object
- Also, GdkRectangle is not an object and so should not have methods
- gdk_pixbuf_get_from_drawable/image - should be functions not methods
- GtkBindingSet, though in the API docs, is not documented, and seems internal
- gtk_drag_get_souce_widget is in gdk.defs, but I feel that it belongs in gtk.defs
- GtkPrivateFlags is not documented and sounds, well, private
- Lots of strange deprecated duplicates that we need to filter out
- Features added to pygtk (compliant to specs): in/out params, user functions, enum/flag values
- Hacked some type names, like G(S)List[type] to specify the component type and [] indicating array
- gdk_pixbuf_save_to_buffer is missing
- THERES A LOT MORE MISSING

---------------------------------
Functions currently UNDOCUMENTED:
---------------------------------

