Re: [Caml-list] OCaml vs Ada and/or GUI options

[Alain Frisch <alain@frisch.fr>]

On 09/12/2013 12:03 AM, Jacques Garrigue wrote:
> BTW, lexifi has also some internal system to build GUIs automatically.
> I don't know if there is a blog post on that.

Indeed, we build GUIs automatically, mapping type definitions to entry 
screens (e.g. a sum type will produce a combobox, a list of record of 
simple types will produce a data grid, etc).  This is based on our 
runtime type extension, and we use attributes on type definitions to 
tweak the GUI layout/behavior (e.g. displaying some float field as a 
percentage, or adding a groupbox around several fields).  Some 
customizations (such as adding buttons) can be added through "patches" 
on the GUI. To specify these patches, we rely on a notion of "type path" 
(strongly typed values describing a path in a data type seen as a tree).

All in all, this is very useful to generate large numbers of entry 
screens without writing any GUI code while ensuring a great level of 
uniformity across the application.  This also makes it possible to 
switch from one underlying GUI technology to another one quite easily 
(our Windows desktop applications currently relies on .NET Windows 
Forms, but we have other GUI backends in place -- including a web based 
one).

Of course, the entire application is not only made of those "uniform" 
entry screens, there are menus, toolbars, interactive charts, pages 
using ad hoc widgets, etc, which are written in a more standard manual 
style.  For these parts, we found it quite convenient to use a 
programming style allowing recursive definitions of controls and 
associated callbacks.  This is described in the "lazy let binding" 
section of this blog post:

  https://www.lexifi.com/blog/ocaml-extensions-lexifi-semi-implicit-laziness

This allows for a more functional style of building GUIs, while keeping 
the standard underlying paradigm (as opposed to FRP GUI frameworks). 
Here is the example from the blog post:

=============================================================
lazy let rec button1 =
   button ~click:(fun () -> button2 # disable) "Button1"
and button2 =
   button ~click:(fun () -> button1 # disable) "Button2"
and my_form =
   form ~title:"Dialog example"
    (hbox
      [
        button1;
        button2;
        button ~click:(fun () -> my_form # close) "Close";
      ]
    )
in
my_form # run_modal
=============================================================

The typical equivalent of this code would require creating the form 
object, the hbox panel, adding widgets to the hbox, adding the hbox to 
the form, setting some text properties, and then registering a callback 
on the buttons.

I guess it would be feasible to write some thin layer on top of LabGTK 
supporting this style (assuming the "lazy let" binding goes upstream!), 
and it would already make the client code look nicer.


Alain