GUI for Ocaml

GUI for Ocaml

[Alain Bengaouer CEA - SYSCO]

	Hi,

As I understand, ocamltk is superseded by LablTk which is included in
Ocaml3 distribution ? Will LablGTk be included as well ?
Is it possible to guess a time schedule for Ocaml3 delivery ? 

Thanks
-- 
---------------------------------------------------------------------
 Alain Bengaouer
 DRN/DMT/SYSCO
 CEA Saclay, Bât 460                   Phone  : 33 (0)1 69 08 84 53
 91191 Gif-sur-Yvette Cedex, France    Fax    : 33 (0)1 69 08 96 96
                                       mailto:Alain.Bengaouer@cea.fr
---------------------------------------------------------------------

Does LablTk have a future?

[Matt Gushee]

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

Re: [Caml-list] Does LablTk have a future?

[Jon Harrop]

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

> 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
http://www.ffconsultancy.com/products/ocaml_for_scientists

GUI for OCaml (was: Re: [Caml-list] Does LablTk have a future?)

[David MENTRE]

Hello,

2005/8/30, Jon Harrop <jon@ffconsultancy.com>:
>  I had tried lablgtk before but failed to get to grips with it. 

The client of my application is also written in Lablgtk2 and, despite
helpful answers by Jacques Garrigue and Olivier Andrieux as well as
SooHyoung Oh's tutorials, I find programming with Labgtk2 not very
easy (to say the least). I find Lablgtk2 is largely under-documented.
Of course, this is a large task that cannot be achieved by two
individuals.

> 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'd also loved too. Having a cross-platform GUI (with native look and
behaviour on Windows and MacOS X),   programmed using a functional
style, well documented (with reference manual and tutorial) and with
necessary tools (GUI design application) would be very very helpful.

However this is a huge task. To add on your initial question:
  1. do you think a minimal part of the OCaml community could
aggregate to ensure the long term maintainability of the toolkit?

  2. how to have a modern look (with whatever definition you might
find for it) which *is* a discriminant point when choosing a GUI?

  3. how to respond to toolkit's users that need to have more "exotic"
widgets/systems?

Yours,
david

Re: GUI for OCaml

[Christophe Raffalli]

David MENTRE a écrit :

 > Hello,
 >
 > 2005/8/30, Jon Harrop <jon@ffconsultancy.com>:
 >
 >> I had tried lablgtk before but failed to get to grips with it.
 >
 >
 >
 > The client of my application is also written in Lablgtk2 and, despite
 > helpful answers by Jacques Garrigue and Olivier Andrieux as well as
 > SooHyoung Oh's tutorials, I find programming with Labgtk2 not very
 > easy (to say the least). I find Lablgtk2 is largely under-documented.
 > Of course, this is a large task that cannot be achieved by two
 > individuals.
 >
 >
 >> 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'd also loved too. Having a cross-platform GUI (with native look and
 > behaviour on Windows and MacOS X),   programmed using a functional
 > style, well documented (with reference manual and tutorial) and with
 > necessary tools (GUI design application) would be very very helpful.
 >

I would prefer a GUI programming language (similar to TeX for word 
processing). This might be easier to develop, can either be static (the 
widget build at compile time) or dynamic, and most of all, it is easier 
to modify an existing GUI.

 > However this is a huge task. To add on your initial question:
 >   1. do you think a minimal part of the OCaml community could
 > aggregate to ensure the long term maintainability of the toolkit?
 >

 >   2. how to have a modern look (with whatever definition you might
 > find for

  it) which *is* a discriminant point when choosing a GUI?

 >

Why a modern look, you should have the look of the OS you are running on,
using the OS X look on OS X,
the windows look on windows,
the KDE (with the user skin) look on KDE etc ...

This is were things are difficult and where a programming language to 
design the GUI is needed, because the GUI elements do not have the same 
dimension on all platform.

 >   3. how to respond to toolkit's users that need to have more "exotic"
 > widgets/systems?
 >

Let's start with simple thing for a basic toolkit,

Then, if the librairy is powerfull enough, it should be possible to 
design new widget entierely in OCaml with the library ?


 > Yours,
 > david
 >
 > _______________________________________________
 > Caml-list mailing list. Subscription management:
 > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
 > Archives: http://caml.inria.fr
 > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
 > Bug reports: http://caml.inria.fr/bin/caml-bugs