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-28 (15:37)
From: Matt Gushee <mgushee@h...>
Subject: Does LablTk have a future?
Hello, list members--

I've been thinking about GUI toolkits lately, and particularly Tk. I 
know there are a lot of people who believe Tk is dead, or should die. 
Personally, I'm not so sure. If you look at the features of Tk 8.5, and 
the development roadmap for future versions--perhaps it's too little, 
too late--but it is clear that the core Tcl/Tk developers are far from 
giving up. Indeed, they seem lately to have gotten a clue about what is 
needed to keep Tk a viable GUI toolkit.

Regardless of the status of Tk itself, LablTk seems to be going nowhere 
(note that I am not implying any criticism of the OCaml team--they have 
other, quite legitimate, priorities). It is poorly documented and is not 
keeping up with the recent improvements in Tk. Those who try to use it 
often run into trouble, and have difficulty getting their questions 
answered. Yet, for whatever reason, it remains the default GUI toolkit 
for OCaml.

I believe that Tk, while certainly not an ideal GUI, is still adequate 
for many applications, and if the above deficiencies are remedied, could 
still serve as OCaml's default GUI library for some time to come. And it 
occurs to me that, having several years' experience with Tk in various 
forms, and having studied much of the LablTk source code, I am in a 
position to do several things that might help revive LablTk. My purpose 
today is to inquire whether there is enough interest in the community to 
justify any or all of these projects. If there is, I am prepared to work 
on one or more of them--preferably with collaborators, but alone if 
necessary. If there is little or no interest, maybe it is time to 
consider (again) dropping LablTk entirely. Who wants to maintain code 
that isn't used or usable?

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.

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

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 eagerly await your comments.

Matt Gushee
Englewood, CO, USA