On 10/13/07, Jon Harrop <jon@ffconsultancy.com> wrote:
> On Friday 12 October 2007 22:58:42 Dario Teixeira wrote:
> > > 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 LablGTK2 bindings to GTK2 by Jacques Garrigue et al. are simply superb
> (robust, efficient and easy to use):

... provided you don't care much about OS X users.

> > The second route involves the OCamIL project (OCaml on .NET) and
> > the Qyoto/Kimono bindings (Qt/KDE bindings for .NET):
>
> Might I suggest that using Microsoft's F# and Microsoft's Windows Forms
> from .NET is an infinitely saner way to approach GUI programming on
> Microsoft's platforms. :-)
>
> Only now that I'm working on Java and Scala code in Eclipse have I come to
> appreciate the awesome combo that F#'s VS mode and Windows Forms provide.
> Although the final GUI code is similar in size between LablGTK/OCaml and
> F#/Windows Forms, developing code in Visual Studio is vastly easier because
> Intellisense lets you explore APIs graphically with no effort.
>
> I would dearly love to see a GUI IDE for OCaml written in OCaml that combined
> simplicity with such a rich form of information throwback.

Me too!  If/when the natdynlink branch lands maybe we'll see something
like this.  (It wouldn't make much sense to do it without plugins.)

Cheers,
-n8

-- 
>>>-- Nathaniel Gray -- Caltech Computer Science ------>
>>>-- Mojave Project -- http://mojave.cs.caltech.edu -->