Re: new draft of defs format

[Karl Nelson <kenelson ece ucdavis edu>]

> I have put up a new draft of the defs format for discussion.  This is
> based on input from the list, Ariel's work and a few changes to make the
> various definitions more consistent, and has been converted to DocBook:
>   http://www.daa.com.au/~james/files/defs.sgml
>   http://www.daa.com.au/~james/files/defs.html
> 
> There are a few places which need clarification.  Suggestions are welcome.
> 
> I was thinking of putting this in CVS along with my "How to write language
> bindings" document.  Sound like a good idea?

Yes, we need a module called language-binding with all the tools needed
to extract defs and info on the requirements for binding.  Add to this
a long list of the things which piss off the binding writers ("if you
do this, we can't bind it.")  


On defs...

Enum:  The numeric-val field may need to be optional as some
rare enums may not be possible to extract or system dependent.  
I of course want it there in any other case.

(define-enum enum-name
   (in-module "module-name")
   (c-name "c-type-name")
   (gtype-id "gtype-code")
   (values
     (short-name symbol-name[ numeric-val])
     ...
   )
 )


Signals:  FIRST/LAST/BOTH may influence the way gtkmm does its
binding. Thus it may need to be extracted into the definition.

(define-signal insert_text
   (of-object "GtkTextBuffer")
   (return-type "none")
   (when "first")
   (parameters
     '("GtkTextIter*" "pos")
     '("gchar*" "text")
     '("gint" "length")
   )
 )

(wasn't this in there at some point.)


Objects:  It appears that the basic definition of what it
is to be an object is subject to some clarification.  I have noticed that
we have at least 2 different object models
  
  1) GObject - pure reference count, no destroy
  2) GtkObject - floating start and destroy

add to this Dia which adds its own floating state to GObject but
not a destroy.  Suddenly  is seems we would need to defined
a how to use this object, is it container like, can it be destroyed later
and such info to the object.  

My understanding is PyGtk is tracing the whole tree to find out
if it comes from GtkObject, but when you are working with 
some widget packaged externally, how can you know that you can pull the
whole defs file down to see what the object model for this object
should be? 

This is practically starting to look like we need model definitions
like boxed to indicate how a derived class from GObject is to be used.



Last,  the situation for me is one of needing the .defs stuff yesterday.
I am taking a new job and only have a short time in between to get my
bindings up to date.
 
We are using an old defs file and need to cut over to the new definitions 
within a week or so.  I have a pile of bindings to write (pangoso getting the 
defs file finalized (in that we will only add new stuff as needed) is
important.  What is the standing of the defs extractor?

--Karl