Towards guile-gtk x.xx

[Daniel Skarda <0rfelyus@atrey.karlin.mff.cuni.cz>]

Hello,

  few days ago I talked with my friend about programming languages. His
  favourite language is (currently :) Python and during debate he frequently
  mentioned that "Python comes with batteries included". This means that
  you install single Python package and get standard modules for nearly
  everything. 

  I think that at this point he is quite right - just imagine you base your
  project on goops, guile-gtk and guileGL. Than users of such project have to
  download and install guile, goops, guile-gtk, guileGL - and possibly other
  guile packages you use. Fortunately nowadays all "serious" packages use
  autoconf - but there is serious labyrinth of version dependencies.

  I am not sure that instant merge of all available packages would be clever - but
  some sort of convergence would be nice. In my opinion following issues should
  be solved to make guile (not only guile-gtk) more useful:

   * Guile should ship with standard way of storage and accessing of C modules
     (shared libraries loading). Today I found try-module-dynamic-link in 
     (ice-9 boot-9) module, but guile-gtk does dynamic linking on its own. I
     would prefer something like (ice-9 libltdl) - guile bindings for libltdl
     library which ships with libtool package.

   * Sometime ago I had to create bindings by hand I have to say that writing
     all these asserts by hand is really painful (and its easy to make mistake -
     ... == 0, ... == SCM_BOOL_F). 

     After some experience with guileGL bindings I am sure that it is not easy
     to create bindings directly from header files - or it is possible just for
     basic types (ints etc) - but when there are arrays and pointers things get
     more complicated.

     I now that there are at least two programs for creating bindings. To be
     honest - I have not tried them. Because I hacked some things in guile-gtk,
     I got used to build-guile-gtk script. I do not know whether all schemers
     would nominate it for best solution but I am sure that Guile should ship
     with such script. So I would like to propose:

        - instead of adding new features to build-guile-gtk we should make it
          more general and separate gtk specific features to special module
          (GuileGL already do this)

        - it would be nice to separate generic functions (enum2scm, scm2enum..)
          from guile-gtk library, thus other bindings do not depend on gtk

	  Also functions for creating new smob types would be useful. As I saw
	  the current define-struct code it depends on gtk library :(

        - To simplify writing and maintaining glue (.defs) files we should
	  provide some mechanism to specify function definitions inside .c
	  files (like SCM_PROC and SCM_MAGIC_SNARFER mechanism):

            SCM_GLUE((define-enum FooType
		       (foo1	MY_FOO_1)
		       (foo2	MY_FOO_2)))

            typedef enum {
              MY_FOO_1,
	      MY_FOO_2
	    } FooType;

  	    SCM_GLUE((define-func foo
  		       int
  		       ((string	  bar)
			(FooType  foot))
  		       (scm-name    "my-foo")))
  	    
  	    int foo(char* bar, FooType foot)
  	    {
  	    .... /* C code */

What do you thing about proposed changes?
Dan Skarda