Re: One more defs user

[Daniel Silva <daniel silva gmail com>]

On Wed, 25 Aug 2004 19:26:53 +0200, Andreas Rottmann <a rottmann gmx at> wrote:
> Daniel Silva <daniel silva gmail com> writes:
> >  However, they seem to be missing some information.
> >
> I assume you talk about the .defs shipped by GTK+. To my knowledge,
> most binding projects maintain their own set of .defs files, with
> hand-added extensions. Here at guile-gnome, we add things such as
> default values and GList types. I really invite you to collaborate
> with guile-gnome in maintaing the .defs files; they are available from
> the defs--dev--0 branch of the guile-gnome archive at
> http://download.gna.org/guile-gnome/archive-2004.

Why do different binding groups use different sets of .defs files
instead of the ones from the GTK+ team?  Would they mind if we added
some extensions to their .defs?

> > For example, gtk_list_store_insert takes a GtkListStore input pointer
> > and a GtkTreeIter output pointer, but gtk.defs and gtk-types.defs
> > don't mention that the second pointer is just for output (a return
> > value).
> >
> [...]
> 
> We don't currently handle output pointers in guile-gnome yet, but
> G-Wrap, the underlying wrapper generator does, so this will be added
> soonish, and is partly in place without editing the .defs file by
> so-called type rules, for instance in glib-spec.scm, we have:
> 
>   [...]
>   (add-type-rule! ws '(("gint*" "*")) '(int out))
> 
> This means: gint* arguments of any name ("*") should be treated as
> integer output arguments. I think such rules are flexible enough to
> handle most or all output arguments that occur in GNOME, but indeed
> explicitly noting this in the .defs as you suggest would be good.
> 
> > The other part missing right now is computed parameters.  For example,
> > in gtk_drag_dest_set:
> >
> [...]
> 
> > targets is actually an array and n_targets is its length.  Neither
> > bits are specified.  Right now I write:
> >
> > (defgtk gtk_drag_dest_set
> >   (_fun _GtkWidgetPtr
> >            _GtkDestDefaults
> >           (targets : (_list i _GtkTargetEntry))
> >           (_int = (length targets))
> >          _GdkDragAction
> >         -> _void))
> >
> > and it would be nice if gtk.specs said something like:
> >
> > (define-method drag_dest_set
> >   (of-object "GtkWidget")
> >   (c-name "gtk_drag_dest_set")
> >   (return-type "none")
> >   (parameters
> >     '("GtkDestDefaults" "flags")
> >     '("const-GtkTargetEntry*" "targets" list)
> >     '("gint" "n_targets" (auto (length "targets")))
> >     '("GdkDragAction" "actions")
> >   )
> > )
> >
> > I don't think any of the additions would break existing tools,
> > considering the first and second elements of the type&name lists stay
> > the same.
> >
> We could use such annotations in guile-gnome, too, but again I
> intended to solve this via "type rules" (array/int support is not yet
> implemented, however).

Hmm, if you want to integrate the type rules and the normal .defs
format, we have to convince the GTK+ people.

Do the GTK+ maintainers keep up with this list?  Can we ask them to
add some things to the .defs files?  We can send patches.

Right now the .defs files say:

(define-method <id>
    (of-object <objName>)
    (c-name <cName>)
    (return-type <type>)
    (parameters <param> ...))

where <id> is a symbol; <objName> and <cName>, and <type> are strings;
and <param> is:

'(<type> <cName>)

I suggest changing <param> to be:

'(<type> <cName> <attrib> ...)
where <attrib> is one of:
  in-pointer
  inout-pointer
  (auto <autoSpec>)
  (non-terminated-array-of <type> <cName of out-param with the length>)
  <rhsAttrib>

where <rhsAttrib> is
  out-pointer
  (null-terminated-array-of <type>)
  (GList-of <type>)

where <autoSpec> is:
   (string-length <cName>)
   (GList-length <cName>)
   (null-terminated-array-length <cName>)
   <constant number>
   c-null

and changing (return-type <type>)  to be (return-type <type> <rhsAttrib> ...).

These changes are pretty inobtrusive (changing <type> would be even
better but would break too many scripts).

I'm betting people need to know these things when binding GTK+ to
Guile, Python, Java, C#, etc. and it would be nice if we all didn't
duplicate efforts.

Daniel