Re: OCaml's long range graphical direction?

[Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>]

I'm moving this thread to the lablgtk mailing, since it is becoming
specific; please remove caml-list from follow-ups. People interested
who are not on the list may see messages on the lablgtk home page.

From: Jerome Vouillon <Jerome.Vouillon@inria.fr>

> On Fri, Feb 09, 2001 at 06:49:01PM +0900, Jacques Garrigue wrote:
> > In fact, the gnome project has a GUI builder called glade, which
> > allows one to produce either C code or an XML representation of the
> > interface. There is even a library libglade which allows one to
> > dynamically load such an XML representation and use it in a program.
> > 
> > It would be pretty easy to either interface to this library,
> 
> I don't think it would be a good idea to interface to this library, as
> it is designed for C, which does not have higher-order function (so,
> the library assumes that there is one function by call-back).

Actually there are also mechanisms provided for interpreted languages.
And interfacing at a basic level is really easy. I added a preliminary
wrapper to lablgtk. Those with CVS access can get it now, and I will
make a snapshot soon.

> > or, more interestingly, build a parser and interpreter for it, so
> > as to be able to use glade's output in lablgtk or mlgtk programs.
> 
> For the parser, one can just use PXP.  The interpreter is a lot of
> work though...  Some time ago, I started to write one, but it only
> supports a few widgets yet.

Yes, and liblglade already interprets for you.
In fact the radtest pure caml approach might be better than that,
since it means that the GUI builder will also be specialized for
caml code, with types and higher-order functions.
But this is lots of work.

> > Still, I'm not sure I would use it personally. Basically, when I write
> > a lablgtk application, the code is not in the GUI layout: this is just
> > one line per widget. It is in all the callbacks and dynamic
> > processing.  I'm not so sure a GUI builder will help you a lot with
> > that, because it can also get in your way.
> 
> I disagree.  When designing an interface, there are a lot of tweakings
> (frame widths, alignements, ...) which are easily done using an
> interface builder but much more tedious to program (and you often need
> to recompile a lot of time to get them right).

Notice that I was talking about myself.  For me this is basically a
TeX vs Word (or LyX), or MagicPoint vs PowerPoint choice.  I always
choose the programming style over the wysiwyg style, others have
different ways. (By the way people here always laugh at me because I
use the mouse with emacs rather than key sequences. Nobody is
perfect.)

For me, with a good toolkit you should not have to tweak that much
small parameters. And when I tweak them, I want means to change
different occurences simultaneously, which the GUI builder wouldn't
let me do.

> > The last problem is how to stay type safe when you load a text file.
> > Basically this means that you will be more verbose, and that will
> > compare badly with guile-gtk or python-gtk based applications.
> 
> I get some code that look like this.  This does not look that verbose to me.
> 
>   let select_date w0 date cont =
>     let gl = interface () in
>     let (w, ctx) =
>       create_dialog gl "choix de la date"
>         ["valider",
>          any (fun ctx _ _ ->
>                 (toplevel ctx)#destroy (); w0#misc#set_sensitive true;
>                 let (year, month, day) = (calendar ctx "calendrier")#date in
>                 cont {day = day; month = month + 1; year = year});
>          "annuler",
>          any (fun ctx _ _ ->
>                 (toplevel ctx)#destroy (); w0#misc#set_sensitive true)]
>     in
>     w0#misc#set_sensitive false;
>     w#set_transient_for w0;
>     begin match date with
>       None -> ()
>     | Some d ->
>         let c = calendar ctx "calendrier" in
>         c#select_month (d.month - 1) d.year;
>         c#select_day d.day
>     end;
>     w#show ()

Your code just demonstrates my point.  With a scripting language, you
would just write calendrier in place of (calendar ctx "calendrier").
And even with this extra verbosity, we have nothing more: typing is
still purely dynamic.
Also, the really hard part is not getting dynamically typed values in
a statically typed language, but the other way round. You cannot
export a callback written in lablgtk style, you have to conform to a
more uniform call syntax, because there is no direct way to get the
actual representation of a typed function.

Here is what I am thinking of doing:
* use libglade, because it already supports all gtk widgets
* extract from the xml file the types of all created widgets, and
  generate ml code to give you objects with the correct types.
  This just amounts to definitions like
       let calendrier = calendar ctx "calendrier"
  You only need to do generate it again when you add or remove
  widgets, not when you tweak parameters.
* leave callbacks completely on the ml side
  That is, only the layout is done by glade,
  everthing else uses lablgtk in the usual way.

This way type checking is dynamic, but happens completely at
initialization time, reducing need for tests.

I've tried thinking of a solution to export callback functions to
libglade, but I couldn't find an easy way to avoid completely dynamic
typing for them , which is something I detest. Imagine an ML program
in which you get a type error when you press a button.

Anybody has good ideas on how to allow writing callbacks with glade?

Jacques