Re: One more defs user

[Andreas Rottmann <a rottmann gmx at>]

Daniel Silva <daniel silva gmail com> writes:

> Hello,
>
> I'm currently writing GTK bindings by hand (to bring GTK into PLT
> Scheme)
>
Cool!

> and would rather use the .defs files.
>
>  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.

> 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).

Regards, Andy
-- 
Andreas Rottmann         | Rotty ICQ      | 118634484 ICQ | a rottmann gmx at
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Python is executable pseudocode, Perl is executable line-noise.