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-09-01 (04:48)
From: Matt Gushee <mgushee@h...>
Subject: Re: Feeding the OCaml GUI troll
First of all, I hope the "troll" label is tongue-in-cheek. I really am 
not trying to stir up argument for argument's sake. The goal is to find 
a project or two that might benefit both myself and the community.

David MENTRE wrote:

> I really fear your under estimate the amount of work needed to
> accomplish such a job. And the OCaml community seems pretty fragmented
> on this GUI front.

Sounds right to me.

>  2. write a *simple* GUI front end, in OCaml, with only simple modules
> and/or simple objects. No fancy use of OCaml type system. Stay close
> to ML core. Use Labgtk2, native Win32 and MacOS X libraries to render
> the GUI. However I don't know the complexity of handling gory details,
> like encoding of strings;

I'm not sold on the idea of a "simple" GUI front end. I've tried one or 
two of them, and I think they're probably good for, say, a database 
application, but useless for more general apps like text editors and 
drawing tools.

>  4. Use Labltk. I can't really comment on it, as I have never used it
> and can't say about its graphical behaviour or desktop integration
> (copy/paste and drag&drop);

Drag and drop would have to be added; copy/paste functionality is a 
built-in feature of the Text widget and possibly some others.

>  5. drop OCaml to write GUI. Use other languages (usually C++) to make
> front-ends and use OCaml code only as backend, communicating through
> sockets or shared memory. Maybe the most viable long term solution.

That's no doubt a technically sound solution. Is it commercially viable? 
I'd say that depends on your market. Large organizations are generally 
comfortable with separately installed components. Small businesses, 
primary and secondary schools (at least in the US), and home users are 
often terrified of complex installation and configuration procedures. 
They want one-step installation.

Matt Gushee
Englewood, CO, USA