From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: * X-Spam-Status: No, score=1.5 required=5.0 tests=SPF_SOFTFAIL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 8F9B5BCC2 for ; Sat, 13 Oct 2007 15:24:44 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAAMwEEfVuiqzn2dsb2JhbACORwEBAQEHBAYJIA X-IronPort-AV: E=Sophos;i="4.21,270,1188770400"; d="scan'208";a="17940561" Received: from 26.mail-out.ovh.net ([213.186.42.179]) by mail4-smtp-sop.national.inria.fr with SMTP; 13 Oct 2007 11:41:51 +0200 Received: (qmail 2974 invoked by uid 503); 13 Oct 2007 09:42:17 -0000 Received: (QMFILT: 1.0); 13 Oct 2007 09:42:17 -0000 Received: from unknown (HELO mail147.ha.ovh.net) (213.186.33.59) by 26.mail-out.ovh.net with SMTP; 13 Oct 2007 09:42:17 -0000 Received: from b0.ovh.net (HELO queue-out) (213.186.33.50) by b0.ovh.net with SMTP; 13 Oct 2007 09:41:15 -0000 Received: from mut38-5-82-246-191-110.fbx.proxad.net (HELO ?82.246.191.110?) (forum%x9c.fr@82.246.191.110) by ns0.ovh.net with SMTP; 13 Oct 2007 09:41:12 -0000 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <348721.45512.qm@web54604.mail.re2.yahoo.com> References: <348721.45512.qm@web54604.mail.re2.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <4D4FF5DB-A749-400E-8508-AB9618AE1409@x9c.fr> Content-Transfer-Encoding: quoted-printable From: "forum@x9c.fr" Subject: Re: [Caml-list] A labltk book? Date: Sat, 13 Oct 2007 11:42:14 +0200 To: caml-list@yquem.inria.fr X-Mailer: Apple Mail (2.752.2) X-Ovh-Remote: 82.246.191.110 (mut38-5-82-246-191-110.fbx.proxad.net) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-Spam: no; 0.00; labltk:01 swig:01 lib:01 bindings:01 bindings:01 ocaml:01 kde:01 ocamlopt:01 marshalling:01 swt:01 smoke:98 smoke:98 routes:98 routes:98 pps:01 Le 12 oct. 07 =E0 23:58, Dario Teixeira a =E9crit : > Hi, > >> you have to go via C so it's much work and the available tools to =20 >> do the >> automagically aren't good enaugh to do it (ok, there is swig, but =20= >> I don't >> like the way the binding is generated). >> There exists the smoke project, it a lib to interface qt and =20 >> python or ruby >> use it to bind to qt (and the next perl qt will also you smoke). =20 >> Maybe that'a > > > I reckon that native bindings might therefore prove nearly impossible! > Two alternate routes have occurred to me though. The first involves > the Ocaml-Java project and Qt-Jambi bindings (basically Qt on the =20 > JVM): > > http://ocamljava.x9c.fr/ > http://trolltech.com/products/qt/jambi > > The second route involves the OCamIL project (OCaml on .NET) and > the Qyoto/Kimono bindings (Qt/KDE bindings for .NET): > > http://www.pps.jussieu.fr/~montela/ocamil/index.html > http://cougarpc.net/qyoto/ > > We've seen recent annoucements concerning the Ocaml-Java project, > so I reckon this route might already be feasible or will be so in > the near future. As for route #2, I don't know the current status > of OCamIL, so it's hard to say. > > Has anyone given any of these routes a try? Perhaps the developers > of Ocaml-Java or OCamIL would like to share their thoughts? Well, I never used Qt, so I can't compare what I propose below to =20 neither Qt nor Jambi. Using OCaml-Java, you can quite easily access Java Swing by two ways : - use Nickel (http://nickel.x9c.fr/) to generate OCaml-to-Java =20= bindings from an xml file describing the classes you are interested in ; - use the Cadmium-SwiXml subproject (http://cadmium.x9c.fr/) = that =20 provides bindings to the SwiXml framework (http://www.swixml.org/) - = SwiXml =20 allows GUI rendering from an xml description. Of course, using OCaml-Java may rise performance issues. If this is a concern, I would consider compiling the "GUI part" using =20= OCaml-Java while having the "engine part" compiled with ocamlopt. Then the two =20 parts could be glued together in a client/server setting, using marshalling of =20 values. Hope this helps, Xavier PS: using Nickel, you can of course generate bindings to other =20 toolkits (e.g. SWT)=