From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id F2642BDE9 for ; Thu, 1 Sep 2005 15:29:10 +0200 (CEST) Received: from ptb-relay04.plus.net (ptb-relay02.plus.net [212.159.14.213]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j81DTADl028344 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 1 Sep 2005 15:29:10 +0200 Received: from [80.229.56.224] (helo=chetara) by ptb-relay04.plus.net with esmtp (Exim) id 1EAp7p-0008MQ-VK for caml-list@yquem.inria.fr; Thu, 01 Sep 2005 14:29:06 +0100 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Does LablTk have a future? Date: Thu, 1 Sep 2005 14:25:58 +0100 User-Agent: KMail/1.7.2 References: <4311DA63.4010104@havenrock.com> <200508301248.24026.jon@ffconsultancy.com> <431680C7.9030800@havenrock.com> In-Reply-To: <431680C7.9030800@havenrock.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200509011425.59176.jon@ffconsultancy.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 43170226.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 labltk:01 labltk:01 ocaml:01 lablgtk:01 recursion:01 memoizing:01 gtk:01 ocaml:01 ocaml-like:01 renderer:01 tracer:01 tracer:01 lablgl:01 guis:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 On Thursday 01 September 2005 05:17, Matt Gushee wrote: > Jon Harrop wrote: > > I meant that the topic "GUI programming using lablTK" is too specific for > > a book. > > Okay, I thought that was probably what you meant. And you're probably > right. There may well be a market for a book on GUI programming in OCaml (including OpenGL). I've managed to get my database app up and running with lablgtk but it required a lot of weirdness (e.g. lots of mutual recursion, a strange "memoizing" wrapper for window creation functions to let me hide and show windows by destroying and recreating them). Having a book on the subject could have saved me a lot of time. The problem is, does anyone know how such things should be written? > Yes, using Text for a spreadsheet is pushing the envelope quite a bit. > It's certainly possible with Canvas. The other option would be to have a > bunch of Text or Entry widgets laid out with the Grid geometry manager. I think GTK will let me do this without too much difficulty. The more I use it and the more hassle I have (most of yesterday was spent making fundamental changes to my implementation, e.g. to let me hide windows) the more I think it would be easier to just start from scratch using OpenGL. > > Yes. As OCaml gains popularity it will be commercially viable to publish > > cheaper books. In the mean time, if you're interested in making money, > > perhaps educational software would be better? > > Okay, you've got my attention. I've had vague thoughts in that direction > myself, and it happens that I taught English as a Second Language for a > few years before getting into geekery. What thoughts do you have about > the opportunities in that field? Vast. Educational software can be cheap because there are no overheads for making and shipping the product. Dispatch is O(1) for the human (you don't have to do anything per order, it is all automated). So it has the moral benefit of letting you help a lot more people whilst also being economically viable. I'm aiming Presenta at the metamarket above this. Ultimately, I hope Presenta will let users write technical slideshow presentations that they can then sell. It will include an embedded (typeset!) OCaml-like DSL that allows users to create and manipulate vector graphics that will be rendered via OpenGL using Smoke, as well as a "manual" vector graphics editor (e.g. like a cut-down version of Corel DRAW). As Presenta is written entirely in OCaml, I may even try to support dynamic loading of code. However, the core (e.g. the renderer) is performance critical and needs to be compiled to native code to achieve good performance. > > Incidentally, OpenGL is extremely important for us. So a GUI toolkit must > > be able to handle OpenGL widgets. Indeed, this begs the question: why not > > do the whole thing in OpenGL? > > It might be a good idea. My starting point was enlightened > self-interest: I know Tk and LablTk fairly well, and I perceive that > LablTk needs some help if it is to remain (become?) useful. Whereas I'm > almost totally ignorant of OpenGL. It's one of the many things I think I > ought to learn, but haven't found time. Have you seen all of the demos on our site? http://www.ffconsultancy.com/products/ocaml_for_scientists/visualisation http://www.ffconsultancy.com/free/maze http://www.ffconsultancy.com/free/ray_tracer http://www.ffconsultancy.com/free/ray_tracer/comparison.html Also, my book has a chapter describing the basics of OpenGL and its use via LablGL. I've already done a lot of work on OpenGL-based GUIs written in OCaml, of course, and I'm willing to help create a decent toolkit. I think we should start with a scene graph and picking. I am particularly interested in peer review of my scene graph design. Perhaps we could use polymorphic variants to make the scene graph extensible? -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. Objective CAML for Scientists http://www.ffconsultancy.com/products/ocaml_for_scientists