To: Benjamin.Monate at lri.fr
Cc: lablgtk at kaba.or.jp
Subject: New snapshot available, with improved glade support
In-Reply-To: <20010515195510.2dd27d22.Benjamin.Monate at lri.fr>
References: <20010515124617.18099399.Benjamin.Monate at lri.fr>
	<20010516002810A.garrigue@kurims.kyoto-u.ac.jp>
	<20010515195510.2dd27d22.Benjamin.Monate@lri.fr>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20010516191251R.garrigue at kurims.kyoto-u.ac.jp>
Date: Wed, 16 May 2001 19:12:51 +0900
From: Jacques Garrigue <garrigue at kurims.kyoto-u.ac.jp>
Lines: 79

Hi,

I just made a new snapshot available, with a glade wrapper
compiler.
   ftp://ftp.kurims.kyoto-u.ac.jp/pub/lang/olabl/lablgtk-20010516.tar.gz 

You can just install it and see what I mean.
There are few other changes. Just a few contributions in the GDK
part.

> > For this to work, both libglade and mlglade stubs should be
> > compatible. A possible way to do that is making the basic interface a
> > simple class, where each method returns a widget in the
> > layout.
> 
> Do you mean an object of a class like :
> 
> class type my_app = object
>     val window1 : GWindow.window
>     val text1 : GEdit.text
> end
>
> I do not see how to plug the callbacks in this structure.

Actually, this is rather

class type my_app = object
  method window1 : GWindow.window
  method text1 : GEdit.text
end

For callbacks, you just write them the usual lablgtk way:

  let my_app = new my_app ~file:"my_app.glade" ;;
  my_app#window1#connect#destroy ~callback:GMain.Main.quit ;;

Basic callbacks (those available by default in Glade) are also
supported (they are bound automatically). You can also add your
own bindings, but this is basically unsafe (Glade makes no coherency
check).
  method extra_handlers : (string * Glade.handler) list

> Here is what mlglade produces on project1.glade in lablgtk examples (Menu
> are not yet supported): 

> (*************************************************)
> (* glade_interface.ml *)
> (* THIS IS A GENERATED FILE : DO NOT EDIT ! *)

The code itself seems OK, but I would prefer it be packed inside a
class, so you can manipulate the widgets without editing the
automatically generated file. Very easy if you are already at that level.

> (*****************************************************)
> (* glade_callbacks.ml
> This file is partly autogenerated. You must change only 
> between two BEGIN/END comments.
> ALL OTHER CHANGES WILL BE DISCARDED !
> In case of problems you can use the .bak file.*)

I'm not really convinced by this part: the lablgtk way seems simpler.
If you really want to help the user writing callbacks, you can add
them as methods in the original class, defaulting to nothing, and
modified by inheritance. But this is only good for beginners: who
would trade the power of first-class functions, for C-style code
pointers, or even for Java method overriding.
Gtk seems to be heading the right way, introducing function closures
in 2.0.

> > Anyway, if you have code ready, I would happily give you a CVS access,
> > so that you can add it to the distribution.
> 
> This is possible but mlglade is still in a very preliminary stage. Isn't
> it too early ?

There are lots of experimental stuff on the CVS anyway.
And this is the natural place for such a tool to be, no?

Jacques