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

[Owen Taylor <owt1 cornell edu>]

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

I should admit first, that I'm not actually responsible for any
language bindings, except informally as a "rooter" for the Perl
bindings. (Anfeuerer, vielleicht? My German dictionary comes up
a bit short. It isn't exactly "Fan" ...) So my comments should just
be taking as kibitzing.

> 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?

Well, I could say "I put the glass on a square piece of wood
with rods attached to the four corners of one face, pointing 
perpendicular to the plane of the wood". But most of us would
rather say "I put the glass on a table". 

Similarly, I think that while it certainly possible for a language
binding to recognize a define-record statement with only "c-field"
slots as a _record_ and then map that onto a record in the language,
it is better not to obscure things in such a manner.

In my opinion, if a C-structure can only be created and destroyed by GTK, 
and only modified in certain ways, it is an object. define-record
should be restricted to pure, plain-and-simple C structures. Things,
like rectangles, that are at least conceptually passed by value.

Now, for languages without a concept of a structure. (i.e., scheme)
it may be nice to specify a standard mapping onto something more
object-like.

For instance, it might be specified that:

(define-record GtkRectangle
   (int x)
   (int y)
   (int width)
   (int height))

Should appear identical in language which don't support records to

(define-boxed GtkRectangle
  (slots
    (int        x
      (mutator  gtk-widget-set-x ...))
    (int        y
      (mutator  gtk-widget-set-y ...)))
  (creator gtk-rectangle-new)
  ...)

Or whatever. But I think there should be a way of explicitely
indicating the simple case, for the benefit of languages that
can handle it. 

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

I'm talking about this, yes. Things like 

(define-function        gtk widget draw
  (description  "force part of widget to be redrawn")
  (returns      none)
  (arguments
    (in          GtkWidget    widget)
    (in optional GdkRectangle rect)))

> or are you talking about the slot-actions?

Default for slots-actions are a GUI builder thing. I'll
leave that for you.

Regards,
                                        Owen