Version française
Home     About     Download     Resources     Contact us    
Browse thread
OCaml's long range graphical direction?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Sven LUTHER <luther@d...>
Subject: Re: OCaml's long range graphical direction?
On Thu, Feb 08, 2001 at 12:01:29PM -0800, Francois Rouaix wrote:
> Okay, my 2 bits on this dicussion; (my credentials are : original designer of 
> the CamlTk interface, writer of MMM. More recently, I've used CamlTk for a 
> production tool in the company I work for).
> 
> I actually think that none of CamlTk/LablTK/LabelGTK fit the most common need 
> in GUI development. In many cases, it still strikes me as utterly boring and 
> time consuming to write *code* to put up menus, buttons, dialogs and such. Of 
> course, from time to time, when you need some form of widget that is a bit 
> original, programming will be useful. But that doesn't happen a lot, unless 
> you write something that needs complex rendering or interaction.
> Back in 1985, Apple started using resources to define interfaces. More 
> recently, Palm used resources again to define interfaces. More recently, 
> Mozilla folks used XML based representation (XUL) to define interfaces, with a 
> GUI level scripting language (JavaScript/ECMAScript).
> This type of approach has, in theory, lots of advantages
>   - forces separation GUI from logic in the code
>   - allows non-programmers to do the GUI design/layout (maybe using 
> interactive tools in the process).
>   - themes easily abstracted
>   - language independence, extensibility, device independence
> 
> I wish that XUL wasn't so bloated (it's basically the whole Mozilla), and that 
> I had time to play with it.
> I would also be interested to know if anybody has explored this realm.

Well, you can do almost the same thing using ocaml modules and functors, which
gives you a good reason to use programing for GUI design.

Basically it goes liek that :

You have one module, which builds the interface.

Then you have a functor, which takes the the callbacks code as parameter and
does the attching of the callbacks to the interface and provides the main GUI
function.

an incomplete example can be found at :

ftp://lambda.u-strasbg.fr/vwck-20010125_1721.tgz

(it provides also some lablgtk + lablgl example, and is GPLed code)

Friendly,

Svne Luther