Re: OCaml's long range graphical direction?

[Sven LUTHER <luther@dpt-info.u-strasbg.fr>]

On Tue, Feb 06, 2001 at 10:28:42AM +0100, Xavier Leroy wrote:
> > Xavier,
> > Please speculate on the future development direction of graphical support
> > in OCaml.
> > Do you anticipate both Tk and GTk being supported?
> > Do you anticipate GTk support being ultimately more desirable and supported
> > than Tk?  If so, what are some of the reasons?
> 
> I'm definitely the wrong person to ask, since I have never written a
> full GUI for a program in all my life :-)  Other members of the OCaml
> development team are much more qualified to answer your questions.
> 
> Still, let me play pointy-haired boss and comment on things I don't
> fully understand.
> 
> 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'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

Err, i don't think so, haven't tried it though, don't own a windows box to
play with it, nor am i in the mood to invest in microsoft developpment tools.

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.

> 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 somethign for the new ocaml consortium ?

Apart from that, i think that for most usage, the current gtk+ bindings are
quite ok.

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.

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

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.

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. 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.

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

That said, i guess there is place in the ocaml world for both a tcl/tk binding
and a gtk+ one. Both are aimed at different uses, and well, as Pierre said the
tcl/tk bindings are not so much work, as they are following a stable tcl/tk.
(well sortof, don't know exactly what it's status is with regard of the
different tcl/tk versions. is anything above 8.0 supported ?)

> > 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 ...

> If multithreading is a requirement, OCaml could probably cope with it
> using the "systems" thread library.
> 
> Let us hear what other members of this list think about this.

Ok, this was my opinion, ...

Friendly,

Sven Luther