Re: Third draft (was Re: defs files)



On Thu, Jan 20, 2000 at 03:14:59PM -0500, Havoc Pennington wrote:
> ===
> (module module-name
>   (submodule-of module-name)) ;; submodule is optional

I don't see the need for this module stuff: we can just name
a GtkCList object GtkCList and use the prefix Gtk. Also
note that some already established bindings may have different
module names then the obvious ones (and that cannot be changed
as it breaks source compatibility). But maybe it's just me:
creating the function bindings from .defs files is nice to
get a binding started, but after that it's only compile-time 
overhead.

> (type
>  (alias some-unique-identifier)
>  (in-module module-name)   ;; optional, gchar* is not in a module
>  (gtk-type-id gtk-type-system-id) ;; optional, absent if this is not
>                                   ;; in the type system
>  (in-c-name name-of-symbol-in-C)
>  (out-c-name name-of-symbol-in-C)
>  (inout-c-name name-of-symbol-in-C))
> 
> Ex: (type
>      (alias string)
>      (gtk-type-id GTK_TYPE_STRING)
>      (in-c-name const-gchar*)
>      (out-c-name gchar**)      ;; actually I'm not sure how strings work out/inout
>      (inout-c-name gchar*))

This is not enough as a string returned from a func could be
malloced or static.

> Whenever a type alias can be used, it is also possible to use the
> keyword "native", which implies that the type in question is too
> C-specific to represent. Then a c-declaration will typically be
> available for use.

I don't know if this will be any use for automated creation of
the binding: could you provide and example usage of c-declaration?

> ===
> (object-argument arg-name

Available at runtime once you know how to init a class, see later.

> === 
> (signal signal-name

Idem.

> === 
> (enum enum-name

Available at runtime, once you know an enum/flag name.

I'd like also to have version information in the defs file.

I think we need two different defs files:
1) one with only the info that cannot be queried at runtime from gtk
   (object names with their class creation functions, enum/flag names, 
   other type descriptions, etc).
2) a defs with function descriptions.

A lot of the info that you want to put in the defs file would be
better queried from the gtk you're going to link with or you're going
to get out of date pretty soon.

lupus



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]