Re: OCaml's long range graphical direction?

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

Salut Francois,

> I actually think that none of CamlTk/LablTK/LabelGTK fit the most
> common need in GUI development. In many cases, it still strikes me
> as utterly boring and time consuming to write *code* to put up
> menus, buttons, dialogs and such. Of course, from time to time, when
> you need some form of widget that is a bit original, programming
> will be useful. But that doesn't happen a lot, unless you write
> something that needs complex rendering or interaction.  Back in
> 1985, Apple started using resources to define interfaces. More
> recently, Palm used resources again to define interfaces. More
> recently, Mozilla folks used XML based representation (XUL) to
> define interfaces, with a GUI level scripting language
> (JavaScript/ECMAScript).
> This type of approach has, in theory, lots of advantages
>   - forces separation GUI from logic in the code
>   - allows non-programmers to do the GUI design/layout (maybe using 
> interactive tools in the process).
>   - themes easily abstracted
>   - language independence, extensibility, device independence

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, 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.
We had more grandiose projects with lablgtk, including creating a real
GUI builder, allowing to input directly Caml code in the interface
design, but this is lots of work for a volunteer effort, so the glade
approach could be a good future direction.

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.

Another aspect is that separating GUI from logic is sometimes going
against modularity. The object-oriented widget approach takes the
widget as a unit for both GUI and logic, which helps in building
programs from parts.  Gtk also handles themes at the widget level.

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.

So, there might be something to do, but I'm not so much convinced it
will help with a language like ocaml.

Amicalement,

Jacques