English version
Accueil     Ŕ propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis ŕ jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml ŕ l'adresse ocaml.org.

Browse thread
Does LablTk have a future?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2005-08-29 (22:36)
From: Jon Harrop <jon@f...>
Subject: Re: [Caml-list] Does LablTk have a future?
On Sunday 28 August 2005 16:38, Matt Gushee wrote:
> Regardless of the status of Tk itself, LablTk seems to be going nowhere

It is odd that you should bring this up now. I've spent the past week writing 
a simple database for a new veterinary surgery in OCaml using labltk. I had 
tried lablgtk before but failed to get to grips with it. By comparison, the 
labktk examples explained everything that I needed and I had a decent GUI up 
and running within a few hours.

May I add another question to this thread: What do people think of OCaml's GUI 
libraries in terms of stability?

> 1) A Quick Reference
>     This document would outline (with little or no explanation) the
>     complete LablTk API, including all widget commands and the possible
>     values of all LablTk-specific types. Currently the latter information
>     can only be obtained by digging through the source code.
>     Actually, I wrote a LablTk quick reference some time ago. It may need
>     a bit of work, but no more than a couple of hours, I'm sure. So I
>     *will* do this if there is any interest at all in it.

I haven't used anything exotic (or even non-trivial) but it seems to me that 
the API is already so simple that there isn't really a need for a quick 

> 2) A Book
>     This would be an in-depth tutorial on how to develop useful
>     applications with LablTk. It would assume some programming
>     experience, but it would not require advanced knowledge of OCaml, nor
>     any knowledge of Tcl.
>     I'm thinking to publish both a print edition and an inexpensive
>     electronic edition. Though I need to research the costs a bit more, I
>     believe I can offer the print edition--self-published using Print On
>     Demand--at a reasonable price, comparable to what you pay for
>     programming books at a bookstore (no, I don't hope to get rich off
>     this--just to be modestly compensated for my efforts ;-).

I think labltk is too specific to be commercially viable. Also, unless I've 
missed some hidden complexities in Tk programming, I think you'd have a job 
filling enough pages to call the result a book.

However, I would be very interested in a book that described how to write GUIs 
using OCaml. I'm still learning how to write and factor "conventional" GUI 
code in OCaml. I have also written custom GUIs using OpenGL (via lablGL) and 
OCaml is superb for this task.

As I'm the author of the only existing self-published book on OCaml, you may 
be interested to know that it is doing well (~500UKP per month for 6 months 
so far). So I would recommend that other people take the plunge and write 
more books on OCaml.

> 3) A Community-based Modernization Project
>     The idea here is to provide a Tk-based GUI library that is complete
>     and in sync with the latest stable version of Tk. Other features that
>     would be nice to have include (a) support for a few Tcl commands that
>     are not strictly part of Tk, but are useful and commonly used in Tk
>     programs--in particular I'm thinking of the 'after' command; and (b)
>     a framework that allows downstream developers to create custom
>     widgets with interfaces analogous to the builtin widgets. I'm not
>     sure if (b) is feasible or not within the constraints of the OCaml
>     type system--I've tried and failed in the  past--but I imagine
>     there's some way to do it.
>     Two other interrelated questions are whether this project should be
>     done in parallel with LablTk or as a replacement, and whether the
>     LablTk API should be preserved or something new designed. But it's
>     probably not necessary to decide these questions immediately.

I think it would be more constructive to create a decent cross-platform GUI 
library from the ground up for FPLs/OCaml. This wouldn't need to be anything 
fancy, just easy access to the simplest GUI elements to start with. I'd like 
to see GUIs described by purely functional data structures. I'm still 
factoring my current code so I'll let you know what I come up with. Also, 
despite GUI code being a pedagogical example for OO, I'm not yet convinced 
that OO adds anything useful.

Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists