To: Benjamin.Monate at lri.fr
Cc: lablgtk at kaba.or.jp
Subject: Re: Glade support
In-Reply-To: <20010517150358.53e582fb.Benjamin.Monate at lri.fr>
References: <20010516033039.18228.cpmta at c012.sfo.cp.net>
	<20010516192110D.garrigue@kurims.kyoto-u.ac.jp>
	<20010517150358.53e582fb.Benjamin.Monate@lri.fr>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20010518103318R.garrigue at kurims.kyoto-u.ac.jp>
Date: Fri, 18 May 2001 10:33:18 +0900
From: Jacques Garrigue <garrigue at kurims.kyoto-u.ac.jp>
Lines: 97

From: Benjamin Monate <Benjamin.Monate@lri.fr>

> > This is very true. For callbacks, you have to see examples.
> > I hope that lablgtk+ocamlbrowser makes it easier to find the available
> > callbacks, but you still have to choose the right one.
> 
> In Glade you have the list of all possibles events related to a given
> widget.

LablGTK tries to do a bit better than that: signals for a GtkLabel
widget in glade contain X events, while a label has no X window, and
as such cannot catch any such event. LablGTK's type system will not
even allow to bind such a useless signal.

> While you design the interface in glade you can add handlers for many
> messages. If there is a generic stub 
> generated for those, you will quickly learn what is called when without
> having to dive into the gtk internals.
> Here mlglade helps a lot the beginners.
> The development process becomes : 
> 1) Visually design in glade
> 2) Choose what messages you want to answer in glade
> 3) Test your empty application to understand if the callbacks are
> registered to the proper events
> 4) Customize the callbacks with your own code
> 5) Go back to 1 or 2 or stop

Sounds like a good process.
Following this good idea, I am going to add signal debugging to
labgladecc :-)

The main practical question for mlglade is then how to handle
customization of callbacks.

> But having a class of default callbacks that you can overide by
> inheritance is much prettier and interacts softly with changes of
> the layout, doesn't it ?

This is a possible solution.
But from a lablgtk point of view, this is not very natural: most
signal bindings are usually done "on the fly", that is without
defining a function, just passing a closure to #connect#somesignal.

I think we enter here the main difference between using glade with C,
and using glade with lablgtk. In C, you're not that much expected to
understand the interface code. As long as you write the code for
callbacks, this should produce a proper GUI. This is because the
interface code is lengthy, and you don't want to write it by hand.

In lablgtk, the interface code is very compact: all the layout only
requires a function call by widget. You want generated code to be as
natural as possible, so that you can use it as example to write by
hand.  And signal binding does not require explicitly defining a
function: passing it as a closure is often more natural.

So I would suggest that you do not include any signal stuff inside
glade_interface.ml, or only for predefined handlers. This would avoid
a spurious backward dependency between glade_interface.ml and
glade_signals.ml (which can be avoided by functors or classes, but
still not very natural).

Then you could generate a glade_signals.ml file of this style,
with inversed dependency:

class window1_debug ... = object (self)
  inherit Glade_interface.window1 ...
  initializer
    self#copy1#connect#activate ~callback:
      (fun () -> prerr_endline "called on_copy1_activate");
    self#window1#event#connect#delete ~callback:
      (fun ev -> prerr_endline "called on_window1_delete_event"; false);
    ...
end

The idea is that you provide debugging code for the signals, which can
also be used as template to define your actual callbacks (with the
proper types). This glade_signals.ml would not have to support editing
itself, you can just copy-paste from it to your real code.

I think this, and the availability of the source code for the
interface, is where mlglade would shine compared to my libglade
approach: you can use it as model for your own development.
But this is also much more work: adding widgets to lablgladecc is
almost automated, since all I need is to know how to cast a widget
to its real class, and I only provide parameterless callbacks.
Yours require knowledge of all the parameters to the lablgtk widget
constructor, how to convert GTK enums to their lablGTK variant
counterpart, and all the parameters for each signal. This is useful,
but I can only wish you good luck.

Maybe this could be made easier by having more of lablGTK
automatically generated. For instance, with GTK enums, you can already
use the gtk_tags.var file.

Best regards,

     Jacques