Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
A labltk book?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2007-10-13 (13:24)
From: <forum@x...>
Subject: Re: [Caml-list] A labltk book?

Le 12 oct. 07 à 23:58, Dario Teixeira a écrit :

> Hi,
>> you have to go via C so it's much work and the available tools to  
>> do the
>> automagically aren't good enaugh to do it  (ok, there is swig, but  
>> I don't
>> like  the way the binding is generated).
>> There exists the smoke project, it a lib to interface qt and  
>> python or ruby
>> use it to bind to qt (and the next perl qt will also you smoke).  
>> 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  
> JVM):
> The second route involves the OCamIL project (OCaml on .NET) and
> the Qyoto/Kimono bindings (Qt/KDE bindings for .NET):
> 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  
neither Qt nor Jambi.

Using OCaml-Java, you can quite easily access Java Swing by two ways :
	- use Nickel ( to generate OCaml-to-Java  
bindings from
	an xml file describing the classes you are interested in ;
	- use the Cadmium-SwiXml subproject ( that  
	bindings to the SwiXml framework ( - SwiXml  
	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  
while having the "engine part" compiled with ocamlopt. Then the two  
parts could
be glued together in a client/server setting, using marshalling of  

Hope this helps,


PS: using Nickel, you can of course generate bindings to other  
toolkits (e.g. SWT)