Re: [gtk-list] Proposal: GUBIs gtk.def

[Tim Janik <Tim Janik Hamburg Netsurf DE>]

On 20 Nov 1997, Owen Taylor wrote:

> 
> I'd still like to see a way to specify structures passed by
> value. Despite what people may think, a rectangle is _not_
> an object with accessors/mutators for x,y, width and height.

hi owen,

first off, i like to make something clear here,
i would like to have a multipurpose gtk+ definition file for
all interpreter glue generators, gui builders, static language glue
generators, etc...
this is to avoid the reinvention of the wheel everytime someone
new is about to generate new bindings for something.
so gluegens purpose is mainly to read in the *.def file you give to it
and then it's up to you to create your glue code for pearl, objective
C, phyton or to just dump the descriptions...

therefore i'm open to _everyones_ requirements/whishes about the description
format and contents.
i for one will just write the parser for the *.defs format and implement
GUBIs glue generator and maybe a description dumper e.g.:

struct  _GlueObject /* this is gluegens internal object representation */
{
  GlueDomain    *domain;
  GlueType      *object_type;
  gchar         *object_name;
  GlueObject    *parent                 /* may be NULL */;
  gchar         *description		/* may be NULL */;
  GList         *children               /* of type GlueObject* */;
  GList         *slots                  /* of type GlueSlot* */;
  GList         *creators               /* of type GlueFunction* */;
  GList         *deferred_creators      /* of type GlueDeferredAction* */;
};

main()
{
	...
	glue_parser_parse_file ("gtk+.defs");
	
	list = glue_get_object_list ();
	while (list)
	{
	  GlueObject *object;
	  if (object->description)
	    printf ("%s - %s\n", object->object_name, object->description);
	  list = list->next;
	}
	...
}

it shouldn't be too difficult for other developers to generate
their stubs by using this scheme.

so if there is something missing you want to be in the file,
propose a format-description and may be even provide the
definitions already in the proposed format, and i'm sure
it will be included.



now concerning the rectangles or misc structures which are not
gtkobjects in general:

so far i've implemented the enum, function and object parsing
in gluegen. i'm currently reworking the define-boxed statement
from marius original gtk.defs format.

as far as i figured a boxed definition of his just mentioned
functions that can be used with it, and sometimes including
an optional "size-detection"-string:

(define-boxed GdkColormap
  gdk_colormap_ref
  gdk_colormap_unref)
(define-boxed GdkEvent
  gdk_event_copy
  gdk_event_free
  "sizeof(GdkEvent)")
(define-boxed GtkTooltips
  gtk_tooltips_ref
  gtk_tooltips_unref)

this doesn't mention the contents, was mainly used for
connecting the reference functions to opaque types.

to have the structure elements described and to have a
more descriptive fucntion connection, we could use
the stubs from the slot mechanism:

(define-record GtkTooltips
  (c-field     accessible      int	numwidgets)
  (c-field     accessible      int	enabled)
  (creator	gtk_tooltips_new)
  (mutator	gtk_tooltips_ref this)
  (mutator	gtk_tooltips_unref this)
  (activator	gtk_tooltips_enable this)
  (deactivator	gtk_tooltips_disable this)
  (mutator	gtk_tooltips_set_delay this variable))
or somesuch...

whereas the c-field definition just looks like the define-object:slots:c-field
statement, and the action definitions are stolen from the slots as well,
with the exception that there are need to be unknown/variable values which
the user specifies later: `variable'.
we could just as well feature the whole slot definition possibilities from
the objects and allow that here as well...
what is your concern?
would that be sufficient?

> 
> Signal specifications seem to a missing ingredient here.

i haven't been up to that till now...
 
> 
> Function arguments should be able to be specified as optional.
> I think this is already in the current gtk.defs spec - if
> so it should definitely be retained.

i'm not sure what you are adressing here, do you mean the
general function definition e.g:

(define-function        gtk widget set-uposition
  (description  "move a widget within its parent window.")
  (returns      none)
  (arguments
    (in GtkWidget       widget)
    (in int             x)
    (in int             y)))

or are you talking about the slot-actions?

(define-object GtkWidget (GtkObject)
  (slots
    (int        x       -2
      (mutator  gtk-widget-set-uposition this  x -2 5))
    (int        y       -2
      (mutator  gtk-widget-set-uposition this -2 y))))


> 
> Regards,
>                                         Owen

---
ciaoTJ