Preferred GUI Toolkit for O'Caml 3?

Preferred GUI Toolkit for O'Caml 3?

[Thorsten Ohl]

I soon have to do major surgery (= an almost complete rewrite) on a
graphical user interface, currently in O'CamlTK.

Since retargeting to incompatible GUIs is such a boring job, I'd like
to hear which toolkit do you see in your tea leafs as the future
toolkit of choice?

   -  O'CamlTK   [ (-) will be superseded by LablTK (I guess)
                   (-) inconvenient (no polymorphic variants) ]

   -  LablTK     [ (+) more convenient than O'CamlTK
                   (+) part of O'Caml 2.99 ]

   -  mlgtk      [ (+) Gtk+ is nicer than Tk (and no-Tcl is nicer than Tcl)
                   (-) is it ported to everything but the kitchen sink? ]

   -  lablgtk    [ same a mlgtk, plus
                   (-) still beta
                   (+) appears(!) to have the slickest API ]

If you don't want to step on someone's toes, you can send me mail,
since I have no intention to start a flame war.

Merci,
-Thorsten
-- 
Thorsten Ohl, Physics Department, TU Darmstadt -- ohl@hep.tu-darmstadt.de
http://heplix.ikp.physik.tu-darmstadt.de/~ohl/ [<=== PGP public key here]

Re: Preferred GUI Toolkit for O'Caml 3?

[Benjamin C. Pierce]

We in the Unison group are also about to embark on a major UI redesign
and have been wondering which toolkit to use.  Besides Thorsten's
points, there are two more that are critical concerns for us:

   * seamless portability (Unix and Win32)
   * ability to build statically linked binaries (this is a pretty
     big drawback to the Tk-based solutions)

Comments on these points as well as the others would be very useful. 

       -- Benjamin

Re: Preferred GUI Toolkit for O'Caml 3?

[William Chesters]

Benjamin C. Pierce writes:
 > We in the Unison group are also about to embark on a major UI redesign
 > and have been wondering which toolkit to use.  Besides Thorsten's
 > points, there are two more that are critical concerns for us:
 > 
 >    * seamless portability (Unix and Win32)
 >    * ability to build statically linked binaries (this is a pretty
 >      big drawback to the Tk-based solutions)
 > 
 > Comments on these points as well as the others would be very useful. 

There's always QT.  It's nice to work with (at least in C++), very
widely used and comprehensive (because of KDE), and was written from
the start to be cross-platform (X & Win).  NB it is uncontroversially
free these days.

Re: Preferred GUI Toolkit for O'Caml 3?

[Alan Schmitt]

Hi,

I'm not sure QT would be so nice to use, since the first problem would
consist of writing the bindings for caml (unless I'm mistaken and they
already exist). I think the best target is definitely gtk, since it
runs under linux and win32, a port on BeOS is in the works, and it is
fairly widely used.

Alan Schmitt

>Benjamin C. Pierce writes:
> > We in the Unison group are also about to embark on a major UI redesign
> > and have been wondering which toolkit to use.  Besides Thorsten's
> > points, there are two more that are critical concerns for us:
> > 
> >    * seamless portability (Unix and Win32)
> >    * ability to build statically linked binaries (this is a pretty
> >      big drawback to the Tk-based solutions)
> > 
> > Comments on these points as well as the others would be very useful. 
>
>There's always QT.  It's nice to work with (at least in C++), very
>widely used and comprehensive (because of KDE), and was written from
>the start to be cross-platform (X & Win).  NB it is uncontroversially
>free these days.
--
The hacker: someone who figured things out and made something cool happen.

Re: Preferred GUI Toolkit for O'Caml 3?

[Sven LUTHER]

On Tue, Feb 22, 2000 at 11:41:06AM +0000, William Chesters wrote:
> Benjamin C. Pierce writes:
>  > We in the Unison group are also about to embark on a major UI redesign
>  > and have been wondering which toolkit to use.  Besides Thorsten's
>  > points, there are two more that are critical concerns for us:
>  > 
>  >    * seamless portability (Unix and Win32)
>  >    * ability to build statically linked binaries (this is a pretty
>  >      big drawback to the Tk-based solutions)
>  > 
>  > Comments on these points as well as the others would be very useful. 
> 
> There's always QT.  It's nice to work with (at least in C++), very
> widely used and comprehensive (because of KDE), and was written from
> the start to be cross-platform (X & Win).  NB it is uncontroversially
> free these days.

But there are no ocaml bindings of it today, so unless someone write some,
they don't are a candidate for an ocaml programmer.

Sure you can always write your interface in C++, and then write binding to
call ocaml function in the callbacks, but it is so nicer to write all
entirely in ocaml. passing ocaml functions as data to callbacks is very nice
to do a lot of thing that would be more complicated using other languages.

What would be nicest would be a toolkit entirely written in ocaml, but i guess
we will not have such a thing in a long time.

One of the advantages of gtk+ (no qt/gtk+ flamewar please) is that it was
designed from the start to support multiple languages binding, in particular
functional ones also, altough they thought mostly of lisp like stuff, wanting
to link with guile.

Friendly,

Sven LUTHER

Re: Preferred GUI Toolkit for O'Caml 3?

[Fabrice Le Fessant]

  
> What would be nicest would be a toolkit entirely written in ocaml, but i guess
> we will not have such a thing in a long time.

  The lattest versions of the Efuns package contain a library called
WXlib, which contains basic widgets build upon the Xlib library
enterely written in Ocaml. Efuns, an Ocaml editor, uses this library
for its menus, scrollbars, file browser, etc ...

A description of Efuns can be found on:

  http://pauillac.inria.fr/efuns

The lattest snapshot(017-1) can be found in:

  http://pauillac.inria.fr/efuns/ftp/

A rpm for linux-i386 + ocaml 2.04 can be found in:

  http://pauillac.inria.fr/efuns/ftp/efuns-0.17.0.0-1.i386.rpm

It contains Efuns, GwML, Xlib, WXlib.

- Fabrice Le Fessant

Homepage: http://pauillac.inria.fr/~lefessan

Re: Preferred GUI Toolkit for O'Caml 3?

[skaller]

Fabrice Le Fessant wrote:
 
>   The lattest versions of the Efuns package contain a library called
> WXlib, which contains basic widgets build upon the Xlib library
> enterely written in Ocaml. Efuns, an Ocaml editor, uses this library
> for its menus, scrollbars, file browser, etc ...
> 
> It contains Efuns, GwML, Xlib, WXlib.

i wonder if you'd like to separate Xlib out?

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net

Re: Preferred GUI Toolkit for O'Caml 3?

[skaller]

"Benjamin C. Pierce" wrote:
> 
> We in the Unison group are also about to embark on a major UI redesign
> and have been wondering which toolkit to use.  Besides Thorsten's
> points, there are two more that are critical concerns for us:
> 
>    * seamless portability (Unix and Win32)
>    * ability to build statically linked binaries (this is a pretty
>      big drawback to the Tk-based solutions)

	I do not understand the latter comment. Tk can be statically
linked, or dynamically linked, or even dynamically loaded as a tcl
package. GTK can also be statically or dynamically linked.

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net

Re: Preferred GUI Toolkit for O'Caml 3?

[Benjamin C. Pierce]

> >    * seamless portability (Unix and Win32)
> >    * ability to build statically linked binaries (this is a pretty
> >      big drawback to the Tk-based solutions)
> 
> 	I do not understand the latter comment. Tk can be statically
> linked, or dynamically linked, or even dynamically loaded as a tcl
> package. GTK can also be statically or dynamically linked.

I've been told that statically linking Tk applications is not
possible.  If you can tell me how to do it (ideally on both Unix and
Windows) I'd be delighted to know: this is one of our biggest problems
with distributing Unison at the moment.

      B

Re: Preferred GUI Toolkit for O'Caml 3?

[Jacques Garrigue]

From: Thorsten Ohl <ohl@hep.tu-darmstadt.de>

> I soon have to do major surgery (= an almost complete rewrite) on a
> graphical user interface, currently in O'CamlTK.
> 
> Since retargeting to incompatible GUIs is such a boring job, I'd like
> to hear which toolkit do you see in your tea leafs as the future
> toolkit of choice?

I answer for the two libraries I'm concerned with.

>    -  LablTK     [ (+) more convenient than O'CamlTK
>                    (+) part of O'Caml 2.99 ]

This is now an integral part of the ocaml distribution, available on
both Unix and Windows (in ocaml 3.00). The interface should be stable
in the future, making it a good choice if portability and
maintainability matter.

>    -  lablgtk    [ same a mlgtk, plus
>                    (-) still beta
>                    (+) appears(!) to have the slickest API ]

Beta does mainly mean that it may undergo API changes in the future.
It is already good enough for writing applications. The next version
will also support Windows.
This is a good choice if appearance matters, and you are ready to
eventually suffer a bit with API changes.

Regards,

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

Re: Preferred GUI Toolkit for O'Caml 3?

[skaller]

Jacques Garrigue wrote:
> 
> From: Thorsten Ohl <ohl@hep.tu-darmstadt.de>
> 
> > I soon have to do major surgery (= an almost complete rewrite) on a
> > graphical user interface, currently in O'CamlTK.
> >
> > Since retargeting to incompatible GUIs is such a boring job, I'd like
> > to hear which toolkit do you see in your tea leafs as the future
> > toolkit of choice?
> 
> I answer for the two libraries I'm concerned with.
> 
> >    -  LablTK     [ (+) more convenient than O'CamlTK
> >                    (+) part of O'Caml 2.99 ]
> 
> This is now an integral part of the ocaml distribution, available on
> both Unix and Windows (in ocaml 3.00). The interface should be stable
> in the future, making it a good choice if portability and
> maintainability matter.
> 
> >    -  lablgtk    [ same a mlgtk, plus
> >                    (-) still beta
> >                    (+) appears(!) to have the slickest API ]
> 
> Beta does mainly mean that it may undergo API changes in the future.
> It is already good enough for writing applications. The next version
> will also support Windows.
> This is a good choice if appearance matters, and you are ready to
> eventually suffer a bit with API changes.

I would beg to differ with this analysis: Tk has some nice widgets,
like the text widget, which are _much_ better than GTK's rather woeful
offering. However, GTK has a tree widget, and while GTK is under
development
-- which is a disadvantage -- it is also under development -- which is
an advantage :-)

Tk is reasonably stable .. but dead. It is also sssllllloooowwwww under
Windows.

IMHO: use Tk if it is enough, and GTK for projects with a serious
future.

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net

Re: Preferred GUI Toolkit for O'Caml 3?

[Gerd Stolpmann]

On Tue, 22 Feb 2000, skaller wrote:
>Tk is reasonably stable .. but dead. It is also sssllllloooowwwww under
>Windows.

It is not only slow under Windows. For example, I had an application with a
"canvas" that displayed many lines of text on the canvas (with some graphical
ornaments), and that changed the event handlers of the objects to display in
the canvas. For only some hundred lines of text, Tk took minutes to set the
canvas up, and the process cosumed about 50 MB of memory. The reason was the
algorithm by which Tk computes the tables that allow Tk to map coordinates to
the sub objects of the canvas.

The problem with Tk is that it has very powerful widgets. Often too powerful in
the wrong direction. But you must use the powerful widgets, because Tk lacks
the possibility to create your own customized widgets by combining several very
simple widgets.

I solved the problem with my canvas widget by redefining the event handler for
the whole widget, and doing the mapping from coordinates to text lines by
myself. This is possible, but you still have to use the super-duper-canvas
widget of Tk.

Tk is fine only for simple GUIs.

Gerd
-- 
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 100             
64293 Darmstadt     EMail:   Gerd.Stolpmann@darmstadt.netsurf.de (privat)
Germany                     
----------------------------------------------------------------------------

Re: Preferred GUI Toolkit for O'Caml 3?

[Sven LUTHER]

On Fri, Feb 18, 2000 at 02:54:10PM +0100, Thorsten Ohl wrote:
> I soon have to do major surgery (= an almost complete rewrite) on a
> graphical user interface, currently in O'CamlTK.
> 
> Since retargeting to incompatible GUIs is such a boring job, I'd like
> to hear which toolkit do you see in your tea leafs as the future
> toolkit of choice?
> 
>    -  O'CamlTK   [ (-) will be superseded by LablTK (I guess)
>                    (-) inconvenient (no polymorphic variants) ]
> 
>    -  LablTK     [ (+) more convenient than O'CamlTK
>                    (+) part of O'Caml 2.99 ]
> 
>    -  mlgtk      [ (+) Gtk+ is nicer than Tk (and no-Tcl is nicer than Tcl)
>                    (-) is it ported to everything but the kitchen sink? ]

huh ???

what do you mean by

"is it ported to everything but the kitchen sink?" ?

it worked fine on my solaris box before, and also under debian gnu/linux ppc
and i386, as well as redhat/sparc. there are reports of it working under
windows also, but i didn't bother to try this broken OS. should work under
beos also, but i don't know if caml works for beos.

Friendly,

Sven LUTHER (one of the three mlgtk developpers).

Re: Preferred GUI Toolkit for O'Caml 3?

[jean-marc alliot]

Hi,

I just have a PhD student who has been working on writing GUIs  with OCAML for
the last months. You might be interested by our experience.

I think first that you can forget ocamltk. It is superseded by LablTk, and the
optional argument feature of OCaml3 is extremely pleasant to use in this
context.

We haven't tested mlgtk. We choosed lablgtk as it is developped by Jacques
Garrigue. It was, for us, a guarantee of good integration with the language.
But mlgtk is probably excellent also.

Our personal opinion would be:
1) If you have no performance problems, labltk is extremely simple to use.
2) Lablgtk is much more efficient and more complex. There might be still some
bugs (?), and you need to invest LOT of your time to learn to do what you want
to do. GTK documentation is quite sparse, and lablgtk documentation is even
sparser. But it is really fast and extremely rich. We have developped a  quite
complex GUI (complete representation of french airspace with ATC sectors etc).
It was painful because of the lack of documentation, but the result is
completely satisfactory regarding performance, and nice to see...



JMA

Re: Preferred GUI Toolkit for O'Caml 3?

[Pascal Cuoq]

>    -  mlgtk      [ (+) Gtk+ is nicer than Tk (and no-Tcl is nicer than Tcl)
>                    (-) is it ported to everything but the kitchen sink? ]
> 
>    -  lablgtk    [ same a mlgtk, plus
>                    (-) still beta
>                    (+) appears(!) to have the slickest API ]

Since Jacques defines "beta" as "the API might change later",
I should point out that mlgtk has had its share of these changes in
the past, and some more may be required in the future.

Personally, I am still working on mlgtk although there are very competent
people working on lablgtk because:

1) it is fun.  It looks good when it works, and when you're tired
   of watching it look good and work well, you change your gtk theme 
   and it feels like you just wrote another toolkit interface, which
   looks good too.

2) some people are actually using it.

Sven, who maintains mlgtk too, told me once that he himself actually 
used it, so that's one more reason why mlgtk should last for a while.

This said, at the time I was recruited to work on mlgtk I had no 
opinion about labels and optional arguments, and now I do: they are
definitely the way to go for a widget library.

There are other differences between the two libraries, because
they were written completely independently.  mlgtk is less object-oriented
in the sense that it relies on module abstraction to be essentially
type-safe from the outside.  I think that lablgtk is completely
type safe, but it has more complicated object hierarchies (if I understood
correctly).

Pascal Brisset, who wrote the interface between mlgtk and native threads,
seemed to be saying that threads were better in mlgtk too :) but that
may have changed...

Pascal