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

[Tim Janik <Tim Janik Hamburg Netsurf DE>]

On Thu, 11 Dec 1997, Owen Taylor wrote:

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

well the point exactly is wether the other party knows about a table
or not... ;)

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

hm, i don't understand in which way _more_ description would
affect an interpreter that couldn't handle it.

for now i'll just leave the boxed information as is:

(define-boxed BOXED_TYPE
   (HANDLER-TYPE
    COPY-HANDLER
    DESTROY-HANDLER))

just get the ugly sizeof-strings out.
so

(define-boxed GdkWindow
  gdk_window_ref
  gdk_window_unref)

(define-boxed GdkColor
  gdk_color_copy
  gdk_color_free
  "sizeof(GdkColor)")

becomes

(define-boxed GdkWindow
  (reference-handlers
    gdk_window_ref
    gdk_window_unref))

(define-boxed GdkColor
  (duplicate-handlers
    gdk_color_copy
    gdk_color_free))

the parser will then enforce to have either `reference-handlers' or
`duplicate-handlers' defined.
new requirements can/will be added as appropriate (and demanded ;)
so as an example, here goes the scheme glue generator
function for boxed types:

void
glue_gen_scm_boxed ()
{
  Glist *list, *free_list;
  free_list = list = glue_get_boxed_list ();
  printf ("sgtk_boxed_info sgtk_boxed_infos[] = {\n");
  while (list)
  {
    GlueBoxed *boxed;
    printf ("  { \"%s",\n"
            "    (void *(*)(void*))%s,\n"
            "    (void (*)(void*))%s,\n",
            boxed->boxed_name,
            boxed->copy_handler->long_name,
            boxed->destroy_handler->long_name);
    if (boxed->handlers_reference)
      printf ("    0 },\n");
    else
      printf ("    sizeof(%s) },\n", boxed->boxed_name);
    list = list->next;
  }
  printf ("  { NULL }\n};");
  g_list_free (free_list);
}

which should produce:
sgtk_boxed_info sgtk_boxed_infos[] = {
  { "GdkWindow",
    (void *(*)(void*))gdk_window_ref,
    (void (*)(void*))gdk_window_unref,
    0 },
  { "GdkColor",
    (void *(*)(void*))gdk_color_copy,
    (void (*)(void*))gdk_color_free,
    sizeof(GdkColor) },
  { NULL }
};

because we are getting the information from an imaginary c-structure
her which might look like
struct GlueBoxed {
  gchar *boxed_name;
  gboolean handlers_reference;
  GlueFunction *copy_handler;
  GlueFunction *destroy_handler;
};

it wouldn't hurt to have additional information for e.g. c-field
identification, just
  GList *c_fields	/* of type GlueCField* */;
or somesuch.

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

hm i have already implemented such kind of thing, and even
posted to the list about it (which isn't new actually, it's used
in the original gtk.defs as well):

> From: Tim Janik <Tim.Janik@Hamburg.Netsurf.DE>
> To: gtk-list@redhat.com
> Subject: [gtk-list] minor gtk+.defs format changes
> 
> [...]
> ; ARG:
> ; (ARG-TYPE TYPE ARG-NAME [DEFAULT-VALUE])
> [...]
> so now the following function definitions are perfectly valid:
> 
> (define-function        gtk box pack-start
>   (returns      none)
>   (arguments
>     (arg-in GtkBox      box)
>     (arg-in GtkWidget   child)
>     (arg-in bool        expand TRUE)
>     (arg-in bool        fill TRUE)
>     (arg-in int         padding 0)))

since then i've just (re-)changed the argument
type, so it can be of {in|out|inout} again...
with the discrete default values it's possible to generate bindings
for e.g. c++ like

class Gtk_Box : public Gtk_Container
{
public:
virtual void	pack_start (Gtk_Widget *child,
			    bool expand = true,
			    bool fill = TRUE,
			    gint padding = 0);
};

i'll omit the code this time ;)

> > or are you talking about the slot-actions?
> 
> Default for slots-actions are a GUI builder thing. I'll
> leave that for you.

hm, actually marius put a lot of ideas into the slots to use
them in scheme somehow...

> 
> Regards,
>                                         Owen

---
ciaoTJ