From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id WAA28486 for caml-red; Sat, 10 Feb 2001 22:36:12 +0100 (MET) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id AAA05394 for ; Sat, 10 Feb 2001 00:31:35 +0100 (MET) Received: from c012.sfo.cp.net (c012-h009.c012.sfo.cp.net [209.228.13.103]) by concorde.inria.fr (8.11.1/8.10.0) with SMTP id f19NVXP23169 for ; Sat, 10 Feb 2001 00:31:34 +0100 (MET) Received: (cpmta 10925 invoked from network); 9 Feb 2001 15:31:29 -0800 Date: 9 Feb 2001 15:31:29 -0800 Message-ID: <20010209233129.10924.cpmta@c012.sfo.cp.net> X-Sent: 9 Feb 2001 23:31:29 GMT Received: from [206.49.216.243] by mail.altavista.com with HTTP; 09 Feb 2001 15:31:29 PST Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 To: Pierre.Weis@inria.fr From: Arturo Borquez Cc: caml-list@inria.fr X-Mailer: Web Mail 3.8.1.6 Subject: Re: OCaml's long range graphical direction? Sender: weis@pauillac.inria.fr To Caml ML: Some reflections about OCaml - GTK I being using GTK libraries for a year and now I am pretty familiarized with it. About a half year I started to use Glade wich is very cool since in low level GTK there are lot of lines to code that Glade do for you (interface.c,h) usually more than 1500 for a modest proyect, and you can concentrate your attention in callbacks (the place where you really code your app). Also XML output of Glade offers flexibility to do parsing to generate skeleton apps to other languages (would be OCaml ... great!). But I agree Jacques Garrige that perhaps it would not be such important as it aparently seems. Why? 1) In LablGtk widgets are packed in classes of higher level than simple bindings 1 : 1, so LablGtk (with the help of labels) tends to be more natural to Caml. 2) Packing widgets is not an issue, you need no more than 2 lines (almost cases 1 line) so a full window can be visualized in a page of code. 3) Most of coding are placed in the callbacks functions so there would be no advantage for Glade. 70% of the code is the app, so GTK interface coding is the less. 4) Glade imposes a static design and could be a drawback for modularization and dynamic construction of objects (during run time) such as variable tables or windows layout thats depend on result of some other function(s). Doing all cases at desing time to fit it in a 'match' would result in a bulky app. 5) LablGtk with -threads offers you viewing your layout as you code, so if you have Copy-Paste facility you can code on a text editor and paste on LablGtk and watch results interactively. 6) Familiarization with LabGtk classes takes a while, but you will find them very productive, labels helps a lot!. As final conclusion I think it's better to concentrate efforts to do a good documentation for LablGtk for those that are not so familiarized with GTK, or deal with the new GTK 2.0. Regards Arturo Borquez Find the best deals on the web at AltaVista Shopping! http://www.shopping.altavista.com