[pygtk] pygtk-codegen - wrapping enums

[Gustavo J. A. M. Carneiro]

On Sex, 2006-02-24 at 10:36 +0100, Jacob Kroon wrote:
> Hi,
> 
> I'm using pygtk-codegen-2.0 to generate python bindings for a library 
> I've written in C.
> The .defs-file contains, among other things :
> 
> ...
> (define-enum SignalType
>  (in-module "Flow")
>  (c-name "FlowSignalType")
>  (gtype-id "FLOW_TYPE_SIGNAL_TYPE")
>  (values
>   '("sinus" "FLOW_SIGNAL_SINUS")
>   )
>  )
> ...
> 
> Now when I modified the C sources, and added another enumeration value, 
> I forgot to update
> the .defs-file - but the enumeration value was still added to the 
> module, and everything was fine.
> 
> Is the "(values)" section really necessary in the .defs-file? Or is it 
> that it _should_ be in the
> .defs-file, but pygtk-codegen doesn't need it, although other language 
> wrappers might need it ?

  This requires a bit of history before I got involved in pygtk, but I
think .defs is a format supposed to be used for multiple language
bindings.

Currently, in PyGTK the enumeration values may be or not used:
     1. If a gtype-id is given, then pygtk disregards and uses gobject
        enumeration introspection from the given GType to get all the
        possible values;
     2. If a gtype-id is missing, then pygtk generates code to register
        the enumeration values.  This can be useful for plain C
        enumerations when the library doesn't register a GType for the
        enum, so there is no GType available.

  Of course, option 1 is always preferable; you get a much nicer
wrapping.  Option 2 is useful when the gtype is missing.

  Hope it helps.

-- 
Gustavo J. A. M. Carneiro
<gjc at inescporto.pt> <gustavo at users.sourceforge.net>
The universe is always one step beyond logic.