To: lablgtk at kaba.or.jp
Subject: libart, and libgnomecanvas
From: Michael Welsh Duggan <md5i at cs.cmu.edu>
Date: Wed, 08 Jan 2003 02:36:37 -0500
Message-ID: <874r8khz3u.fsf at cs.cmu.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: Michael Welsh Duggan <md5i at md5i.dsl.telerama.com>

I've been hacking lablgtk2-alpha in order to add libart and
libgnomecanvas support.  libart support has been fairly
straightforward, but I am unsure as to the best way to proceed for
libgnomecanvas.

In particular, I need to be able to support more than just the
addition of new signals to new classes.  Most new canvas items will
want to override a method or two.  My first attempt uses record of
closures, much like this:

    type type_class =
        { update: (canvas_item obj -> affine:(Affine.t option) -> 
          SVP.t -> update_flags list -> unit) option;
          realize: (canvas_item obj -> unit) option;
          unrealize: (canvas_item obj -> unit) option;
          map: (canvas_item obj -> unit) option;
          unmap: (canvas_item obj -> unit) option;
          coverage: (canvas_item obj -> SVP.t) option;
          draw: (canvas_item obj ->  drawable_types drawable ->
            x:int -> y:int -> width:int -> height:int -> unit) option;
          render: (canvas_item obj -> canvasbuf -> unit) option;
          point: (canvas_item obj -> x:float -> y:float ->
            cx:int -> cy:int -> (float * canvas_item obj)) option;
          bounds: (canvas_item obj -> (float * float * float * float))
            option;
          event: (canvas_item obj -> GdkEvent.any -> bool) option}

But is this really the best way to go about this sort of thing?  It
seems a little ad-hoc to me.  Also, it would seem like it would be
good to have a programmatic way to add to and update the
widget_info_array, as new libraries shouldn't have to modify
ml_gtknew.c and gtkNew.ml in order to use signal_new.

-- 
Michael Welsh Duggan
(md5i@cs.cmu.edu)