To: Jerome.Vouillon at inria.fr, lablgtk at kaba.or.jp Cc: caml-list at inria.fr Subject: Re: OCaml's long range graphical direction? In-Reply-To: <20010209205803.A7869 at pauillac.inria.fr> References: <200102082001.f18K1VH08374 at nez-perce.inria.fr> <20010209184901V.garrigue@kurims.kyoto-u.ac.jp> <20010209205803.A7869@pauillac.inria.fr> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010210213638M.garrigue at kurims.kyoto-u.ac.jp> Date: Sat, 10 Feb 2001 21:36:38 +0900 From: Jacques Garrigue Lines: 122 I'm moving this thread to the lablgtk mailing, since it is becoming specific; please remove caml-list from follow-ups. People interested who are not on the list may see messages on the lablgtk home page. From: Jerome Vouillon > On Fri, Feb 09, 2001 at 06:49:01PM +0900, Jacques Garrigue wrote: > > In fact, the gnome project has a GUI builder called glade, which > > allows one to produce either C code or an XML representation of the > > interface. There is even a library libglade which allows one to > > dynamically load such an XML representation and use it in a program. > > > > It would be pretty easy to either interface to this library, > > I don't think it would be a good idea to interface to this library, as > it is designed for C, which does not have higher-order function (so, > the library assumes that there is one function by call-back). Actually there are also mechanisms provided for interpreted languages. And interfacing at a basic level is really easy. I added a preliminary wrapper to lablgtk. Those with CVS access can get it now, and I will make a snapshot soon. > > or, more interestingly, build a parser and interpreter for it, so > > as to be able to use glade's output in lablgtk or mlgtk programs. > > For the parser, one can just use PXP. The interpreter is a lot of > work though... Some time ago, I started to write one, but it only > supports a few widgets yet. Yes, and liblglade already interprets for you. In fact the radtest pure caml approach might be better than that, since it means that the GUI builder will also be specialized for caml code, with types and higher-order functions. But this is lots of work. > > Still, I'm not sure I would use it personally. Basically, when I write > > a lablgtk application, the code is not in the GUI layout: this is just > > one line per widget. It is in all the callbacks and dynamic > > processing. I'm not so sure a GUI builder will help you a lot with > > that, because it can also get in your way. > > I disagree. When designing an interface, there are a lot of tweakings > (frame widths, alignements, ...) which are easily done using an > interface builder but much more tedious to program (and you often need > to recompile a lot of time to get them right). Notice that I was talking about myself. For me this is basically a TeX vs Word (or LyX), or MagicPoint vs PowerPoint choice. I always choose the programming style over the wysiwyg style, others have different ways. (By the way people here always laugh at me because I use the mouse with emacs rather than key sequences. Nobody is perfect.) For me, with a good toolkit you should not have to tweak that much small parameters. And when I tweak them, I want means to change different occurences simultaneously, which the GUI builder wouldn't let me do. > > The last problem is how to stay type safe when you load a text file. > > Basically this means that you will be more verbose, and that will > > compare badly with guile-gtk or python-gtk based applications. > > I get some code that look like this. This does not look that verbose to me. > > let select_date w0 date cont = > let gl = interface () in > let (w, ctx) = > create_dialog gl "choix de la date" > ["valider", > any (fun ctx _ _ -> > (toplevel ctx)#destroy (); w0#misc#set_sensitive true; > let (year, month, day) = (calendar ctx "calendrier")#date in > cont {day = day; month = month + 1; year = year}); > "annuler", > any (fun ctx _ _ -> > (toplevel ctx)#destroy (); w0#misc#set_sensitive true)] > in > w0#misc#set_sensitive false; > w#set_transient_for w0; > begin match date with > None -> () > | Some d -> > let c = calendar ctx "calendrier" in > c#select_month (d.month - 1) d.year; > c#select_day d.day > end; > w#show () Your code just demonstrates my point. With a scripting language, you would just write calendrier in place of (calendar ctx "calendrier"). And even with this extra verbosity, we have nothing more: typing is still purely dynamic. Also, the really hard part is not getting dynamically typed values in a statically typed language, but the other way round. You cannot export a callback written in lablgtk style, you have to conform to a more uniform call syntax, because there is no direct way to get the actual representation of a typed function. Here is what I am thinking of doing: * use libglade, because it already supports all gtk widgets * extract from the xml file the types of all created widgets, and generate ml code to give you objects with the correct types. This just amounts to definitions like let calendrier = calendar ctx "calendrier" You only need to do generate it again when you add or remove widgets, not when you tweak parameters. * leave callbacks completely on the ml side That is, only the layout is done by glade, everthing else uses lablgtk in the usual way. This way type checking is dynamic, but happens completely at initialization time, reducing need for tests. I've tried thinking of a solution to export callback functions to libglade, but I couldn't find an easy way to avoid completely dynamic typing for them , which is something I detest. Imagine an ML program in which you get a type error when you press a button. Anybody has good ideas on how to allow writing callbacks with glade? Jacques