To: Benjamin.Monate at lri.fr
Cc: lablgtk at kaba.or.jp
Subject: Re: Glade support
In-Reply-To: <20010515124617.18099399.Benjamin.Monate at lri.fr>
References: <20010515113847.74211da1.Benjamin.Monate at lri.fr>
	<20010515184710E.garrigue@kurims.kyoto-u.ac.jp>
	<20010515124617.18099399.Benjamin.Monate@lri.fr>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20010516002810A.garrigue at kurims.kyoto-u.ac.jp>
Date: Wed, 16 May 2001 00:28:10 +0900
From: Jacques Garrigue <garrigue at kurims.kyoto-u.ac.jp>
Lines: 45

Hello Benjamin,

After second thought, I think your approach can be very useful, and at
two levels.

The first one is for beginners: this can help them write their first
programs, generating the difficult part of the code, before they
familiarize themselves with lablgtk.
This part becomes less interesting once you know more of lablgtk.
Also, lablgtk is very strong at callbacks, so that having the
callback stubs generated automatically is not a great boon.

The second one is complementary with the libglade based approach: once
you have fixed your layout, you can get rid of libglade by generating
the code.

I still think that libglade is better during development: you can
build a first GUI, build your program around it, and then refine the
layout _without recompiling the program_. This greatly improves design
speed: you switch between glade and program testing, without compiling
or linking.

And generating stubs for libglade is very easy: you just need to
extract widget names and their classes from the glade description. See
how you can obtain window1 and text1 in glade_demo.ml. You don't even
need a full fledge parser for that.

So, in an ideal view, mlglade and libglade would be complementary: 
you first generate libglade stubs, and build your program around them,
refining the program and the GUI. Once you're statisfied with the
result, you generate your final code with mlglade, and have a running
application, with no unnecessary dependencies.

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. Classes are better than modules at this, because they can be
used dynamically.

Anyway, if you have code ready, I would happily give you a CVS access,
so that you can add it to the distribution.

Best regards,

Jacques