From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 3E3997EE4A for ; Thu, 12 Sep 2013 10:16:25 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of alain@frisch.fr) identity=pra; client-ip=193.252.23.212; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="alain@frisch.fr"; x-sender="alain@frisch.fr"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of alain@frisch.fr) identity=mailfrom; client-ip=193.252.23.212; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="alain@frisch.fr"; x-sender="alain@frisch.fr"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@msa.smtpout.orange.fr) identity=helo; client-ip=193.252.23.212; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="alain@frisch.fr"; x-sender="postmaster@msa.smtpout.orange.fr"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsBANl3MVLB/BfUnGdsb2JhbABbDoMxwSaBOA4BAQEBAQYWCTyCJQEBBScRQAEQCxgJFg8JAwIBAgE3AQ0GAQwBBwEBiAIIvEwEjzgzB4QdA5d5hi+OJkE X-IPAS-Result: AqsBANl3MVLB/BfUnGdsb2JhbABbDoMxwSaBOA4BAQEBAQYWCTyCJQEBBScRQAEQCxgJFg8JAwIBAgE3AQ0GAQwBBwEBiAIIvEwEjzgzB4QdA5d5hi+OJkE X-IronPort-AV: E=Sophos;i="4.90,889,1371074400"; d="scan'208";a="26578464" Received: from msa03.smtpout.orange.fr (HELO msa.smtpout.orange.fr) ([193.252.23.212]) by mail3-smtp-sop.national.inria.fr with ESMTP; 12 Sep 2013 10:16:24 +0200 Received: from [192.168.1.112] ([92.151.61.120]) by mwinf5d64 with ME id Q8GN1m00P2bfMm4038GNkr; Thu, 12 Sep 2013 10:16:23 +0200 Message-ID: <52317856.5000906@frisch.fr> Date: Thu, 12 Sep 2013 10:16:22 +0200 From: Alain Frisch User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Jacques Garrigue , David MENTRE CC: OCaml Mailing References: <20130910230928.2d51cd39@atmarama.noip.me> <20130911052437.GA9514@notk.org> <843DB424-8563-45A7-A22A-2FA65338298B@math.nagoya-u.ac.jp> In-Reply-To: <843DB424-8563-45A7-A22A-2FA65338298B@math.nagoya-u.ac.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] OCaml vs Ada and/or GUI options 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