From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 24F0DBDCB for ; Tue, 30 Aug 2005 18:04:45 +0200 (CEST) Received: from pih-relay06.plus.net (fuzznuts.plus.net [212.159.14.133] (may be forged)) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j7UG4ibO005992 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 30 Aug 2005 18:04:44 +0200 Received: from [80.229.56.224] (helo=chetara) by pih-relay06.plus.net with esmtp (Exim) id 1EA8bJ-0005k3-O6 for caml-list@yquem.inria.fr; Tue, 30 Aug 2005 17:04:43 +0100 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: GUI for OCaml (was: Re: [Caml-list] Does LablTk have a future?) Date: Tue, 30 Aug 2005 17:01:49 +0100 User-Agent: KMail/1.7.2 References: <4311DA63.4010104@havenrock.com> <3d13dcfc050830001671d0974f@mail.gmail.com> <20050830141430.GA16012@furbychan.cocan.org> In-Reply-To: <20050830141430.GA16012@furbychan.cocan.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508301701.49824.jon@ffconsultancy.com> X-Miltered: at concorde with ID 4314839C.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; ocaml:01 caml-list:01 labltk:01 lablgtk:01 gtk:01 lablgtk:01 ocaml:01 api:01 snippets:01 rec:01 widget:01 widget:01 hbox:01 vbox:01 statically:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 On Tuesday 30 August 2005 15:14, Richard Jones wrote: > Lablgtk2 is a pain, but I think the pain comes from Gtk itself, not > any shortcomings in lablgtk2 or ocaml. Yes. My understanding is that lablgtk does a lot to hide the hideousness beneath. > > However this is a huge task. [...] > > It is a huge task. Depending on what exactly we're talking about, I think it is entirely tractable for one person, let alone a team. > I'm not even sure what a "functional" API for a > GUI toolkit would look like. Ideas? Example code snippets? I think the GUI code should be split into definition (i.e. how the widgets are laid out) and execution (i.e. what functions are called for GUI events). The former should be functional in style because it is easier to write and more succinct and the latter should be imperative in style because it is essentially poking a state machine about. The functional definition could be a data structure that is folded over to accumulate the widgets needed by the subsequent event code. For example, consider a searchable list with a labelled search box, a scrollable list and a button to add new entries (off the top of my head): let gui = `Frame [`Frame [`Label "Search: "; `Entry]; `List; `Button "Add"];; let rec make parent accu = function | `Frame l -> List.fold_left (make (Frame.create `Top parent)) accu l | `Label text -> let widget = Label.create ~text parent in pack [widget]; `Label widget :: accu | `Entry -> let widget = Entry.create parent in pack [widget]; `Entry widget :: accu | `List -> let parent = build_frame side fill expand parent in let list = Listbox.create ~width parent in pack ~side:`Left ~fill:`Both ~expand:true [list]; let scroll_bar = Scrollbar.create parent in Listbox.configure ~yscrollcommand:(Scrollbar.set scroll_bar) list; Scrollbar.configure ~command:(Listbox.yview list) scroll_bar; pack ~side:`Right ~fill:`Y [scroll_bar]; `List list :: accu | `Button text -> let widget = Button.create ~text parent in pack [widget]; `Button widget :: accu let [_; `Entry search; `List list; `Button add] = make top [] gui;; You'd want to add a call to "pack" after each call to "*.create" and you'd want to have HBox and VBox instead of Frame but the basic idea is there. I can't see a good way to statically type such code in general so I've left it with an incomplete pattern match. Perhaps we should start by writing such a wrapper that can target either labltk or lablgtk? -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. Objective CAML for Scientists http://www.ffconsultancy.com/products/ocaml_for_scientists