Re: OCaml's long range graphical direction?

[Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>]

As current maintainer of LablTk and LablGTK, I try to answer a bit on
these questions. But do not expect a real vision from me: what will
stay is what people are using, that seems enough for me. And if people
want to see more development on LablTk and/or CamlTk, I would see
nothing wrong in it.

Also, since somebody suggest me that more publicity could be good,
there is now a lablgtk mailing list. See info on the lablgtk home
page: http://wwwfun.kurims.kyoto-u.ac.jp/soft/olabl/lablgtk.html

> On Tue, Feb 06, 2001 at 10:28:42AM +0100, Xavier Leroy wrote:
[disclaimer erased]
> > I expect the Caml-TK interface to be supported (and included in the
> > standard OCaml distribution) for quite a while, but not actively
> > developed.  TK itself is quite stable and is available for many
> > platforms: Unix, Windows, and MacOS.  TK does well what it's been
> > designed to do: write quickly simple GUIs.  It starts to break apart
> > for really complex GUIs, as the development of the MMM Web browser
> > demonstrated.

I'm not sure it really breaks apart: to me MMM was rather successfull.
But it is difficult to completely control the look-and-feel of an
application with Tcl/Tk, and the weakness of the thread support may be
a problem for some specific uses (including a web browser).
And as often pointed out, not everybody agrees with the direction
Tcl/Tk is going to (strong investment on scripting).

A small correction: there is currently no support for the MacOS
version with Caml. No idea of how difficult it would be, but there was
no huge demand for it.

> > I've heard lots of good things about GTK, and it looks more powerful
> > than TK, so it might be the wave of the future.  However, it is my
> > impression that the Windows port of GTK is lagging behind.  Also, the

It is there, this is already a lot :-)
And some lablgtk applications are already ported to windows.

From: Sven LUTHER <luther@dpt-info.u-strasbg.fr>

> Also there is work underway for a framebuffer port of gtk+, this could be a
> nice tool for embeded system running only ocaml or some variant thereof. I
> think we will see macos X support soon, if you don't want to use X on it.

Yes, the activity around GTK+ is very encouraging.

> > Caml-GTK interface is still actively developed and hence might be less
> > stable than the Caml-TK interface.
> 
> And with the forthcoming of gtk+ 2.0, there is need for a lot of work in that
> area.
> 
> Maybe this is something for the new ocaml consortium ?

Not so sure: interfacing to GTK requires quite a bit of design, and
I'm not sure how much of it can be delegated.
Anybody knows when GTK+ 2.0 will be ready, anyway?

> That said, we still have 2 gtk+ bindings, at least.
> It seems lablgtk is more complete and may have more active support, due maybe
> because jacques as more time to devote to it than i and pascal cuoq do.
> But still mlgtk seems more easy to understand and to use, needing less
> understanding of the convoluted class and methods system that lablgtk uses.
> Both lack good documentation, well apart from the source that is.

This convoluted class and method system is intended to make using
lablgtk easier on the long term :-)
In fact, people seem to be coping with it OK. That is, I didn't get
that many questions on it. But certainly, there is a huge deficit in
documentation.

> It would be nice to know who is using which of the bindings and what is their
> opinion on it ?

Yes, for sure, I'd love to here more.
I had a bit of feedback for lablgtk: Pierce&Jim's unison (I forced
lablgtk on them by writing a UI), an airplane route analysis tool, a
frontend for a database, etc...
Also somebody here developped an irc client, and a binding for
mozilla's gecko for another project. We shall make the effort to
release these individually.
 
> Also both use an object layer over an type unsafe non object layer. It seems
> that this seems an hindrance for some, from previous comment on this.

Not completely exact: the non-object layer is also type safe in
lablgtk. You theoretically can program in it directly. This is just
going to be much more verbose. Also a bit more error-prone, since not
everything is captured by the type system.

> Ideally it would be nice to have a stub layer that will be used by both
> bindings, if they are not merged, and could even be used standalone or with a
> more type safe non object wrapping, if this is possible.

Personally I would rather favor a merge of the two-bindings. I believe
this is what most people want, and there is enough work for both
teams.
Or would it be possible to build a mlgtk compatible layer on top of
lablgtk's non-object layer?

> Also i advocate the use of automatic or semi-automatic translation
> of the gtk+ C headers for creating the stub layer, so as to make the
> tracking of changes in gtk+ easier.

I'm all for it. But this is lots of work, especially if you want the
intermediate layer to be typed.

> But then again, this is work that need to be done, and i personnaly
> don't have the time for it.

All problems come to that :-)

> > > To what degree does threading affect the answer?
> > 
> > No idea.  I've heard plenty of claims that multithreading helps
> > building good GUIs (see e.g. BeOS), yet most popular GUIs (including
> > TK and I think GTK too) seem to manage fine without multithreading.  
> 
> Well, from Jacques message, gtk+ is thread safe, while tcl/tk is not.
> 
> Now i don't know if that helps a lot. Personnally i don't use threads when
> writing GUIs, and am still strugling with modules and functors for it ...

This helps when you build network applications: you naturally want to
have multiple threads, and having to route all GUI calls through a
single thread is a pain.

Remark however that lablgtk does not really use gtk's (partial)
thread-safety: caml programs use a central lock anyway. The difference
is that lablgtk's code is reentrant, and camltk/labltk code is not
(due to a large number of tables to handle callbacks). But gtk's
re-entrance may come handy at some other time.

Cheers,

Jacques Garrigue
---------------------------------------------------------------------------
Jacques Garrigue      Kyoto University     garrigue at kurims.kyoto-u.ac.jp
		<A HREF=http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/>JG</A>