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 TAA15105 for caml-red; Thu, 8 Feb 2001 19:48:02 +0100 (MET) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id CAA18161 for ; Thu, 8 Feb 2001 02:59:58 +0100 (MET) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f181xuH18310 for ; Thu, 8 Feb 2001 02:59:56 +0100 (MET) Received: from localhost (mikan.kurims.kyoto-u.ac.jp [130.54.16.202]) by kurims.kurims.kyoto-u.ac.jp (8.9.3/3.7W) with ESMTP id KAA09081; Thu, 8 Feb 2001 10:59:41 +0900 (JST) To: luther@dpt-info.u-strasbg.fr Cc: caml-list@inria.fr Subject: Re: OCaml's long range graphical direction? In-Reply-To: <20010206191902.B11976@lambda.u-strasbg.fr> References: <20010206102842.A27059@pauillac.inria.fr> <20010206191902.B11976@lambda.u-strasbg.fr> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010208105941X.garrigue@kurims.kyoto-u.ac.jp> Date: Thu, 08 Feb 2001 10:59:41 +0900 From: Jacques Garrigue X-Dispatcher: imput version 20000228(IM140) Sender: weis@pauillac.inria.fr As current maintainer of LablTk and LablGTK, I try to answer a bit on these questions. But do not expect a real vision from me: what will stay is what people are using, that seems enough for me. And if people want to see more development on LablTk and/or CamlTk, I would see nothing wrong in it. Also, since somebody suggest me that more publicity could be good, there is now a lablgtk mailing list. See info on the lablgtk home page: http://wwwfun.kurims.kyoto-u.ac.jp/soft/olabl/lablgtk.html > On Tue, Feb 06, 2001 at 10:28:42AM +0100, Xavier Leroy wrote: [disclaimer erased] > > I expect the Caml-TK interface to be supported (and included in the > > standard OCaml distribution) for quite a while, but not actively > > developed. TK itself is quite stable and is available for many > > platforms: Unix, Windows, and MacOS. TK does well what it's been > > designed to do: write quickly simple GUIs. It starts to break apart > > for really complex GUIs, as the development of the MMM Web browser > > demonstrated. I'm not sure it really breaks apart: to me MMM was rather successfull. But it is difficult to completely control the look-and-feel of an application with Tcl/Tk, and the weakness of the thread support may be a problem for some specific uses (including a web browser). And as often pointed out, not everybody agrees with the direction Tcl/Tk is going to (strong investment on scripting). A small correction: there is currently no support for the MacOS version with Caml. No idea of how difficult it would be, but there was no huge demand for it. > > I've heard lots of good things about GTK, and it looks more powerful > > than TK, so it might be the wave of the future. However, it is my > > impression that the Windows port of GTK is lagging behind. Also, the It is there, this is already a lot :-) And some lablgtk applications are already ported to windows. From: Sven LUTHER > Also there is work underway for a framebuffer port of gtk+, this could be a > nice tool for embeded system running only ocaml or some variant thereof. I > think we will see macos X support soon, if you don't want to use X on it. Yes, the activity around GTK+ is very encouraging. > > Caml-GTK interface is still actively developed and hence might be less > > stable than the Caml-TK interface. > > And with the forthcoming of gtk+ 2.0, there is need for a lot of work in that > area. > > Maybe this is something for the new ocaml consortium ? Not so sure: interfacing to GTK requires quite a bit of design, and I'm not sure how much of it can be delegated. Anybody knows when GTK+ 2.0 will be ready, anyway? > That said, we still have 2 gtk+ bindings, at least. > It seems lablgtk is more complete and may have more active support, due maybe > because jacques as more time to devote to it than i and pascal cuoq do. > But still mlgtk seems more easy to understand and to use, needing less > understanding of the convoluted class and methods system that lablgtk uses. > Both lack good documentation, well apart from the source that is. This convoluted class and method system is intended to make using lablgtk easier on the long term :-) In fact, people seem to be coping with it OK. That is, I didn't get that many questions on it. But certainly, there is a huge deficit in documentation. > It would be nice to know who is using which of the bindings and what is their > opinion on it ? Yes, for sure, I'd love to here more. I had a bit of feedback for lablgtk: Pierce&Jim's unison (I forced lablgtk on them by writing a UI), an airplane route analysis tool, a frontend for a database, etc... Also somebody here developped an irc client, and a binding for mozilla's gecko for another project. We shall make the effort to release these individually. > Also both use an object layer over an type unsafe non object layer. It seems > that this seems an hindrance for some, from previous comment on this. Not completely exact: the non-object layer is also type safe in lablgtk. You theoretically can program in it directly. This is just going to be much more verbose. Also a bit more error-prone, since not everything is captured by the type system. > Ideally it would be nice to have a stub layer that will be used by both > bindings, if they are not merged, and could even be used standalone or with a > more type safe non object wrapping, if this is possible. Personally I would rather favor a merge of the two-bindings. I believe this is what most people want, and there is enough work for both teams. Or would it be possible to build a mlgtk compatible layer on top of lablgtk's non-object layer? > Also i advocate the use of automatic or semi-automatic translation > of the gtk+ C headers for creating the stub layer, so as to make the > tracking of changes in gtk+ easier. I'm all for it. But this is lots of work, especially if you want the intermediate layer to be typed. > But then again, this is work that need to be done, and i personnaly > don't have the time for it. All problems come to that :-) > > > To what degree does threading affect the answer? > > > > No idea. I've heard plenty of claims that multithreading helps > > building good GUIs (see e.g. BeOS), yet most popular GUIs (including > > TK and I think GTK too) seem to manage fine without multithreading. > > Well, from Jacques message, gtk+ is thread safe, while tcl/tk is not. > > Now i don't know if that helps a lot. Personnally i don't use threads when > writing GUIs, and am still strugling with modules and functors for it ... This helps when you build network applications: you naturally want to have multiple threads, and having to route all GUI calls through a single thread is a pain. Remark however that lablgtk does not really use gtk's (partial) thread-safety: caml programs use a central lock anyway. The difference is that lablgtk's code is reentrant, and camltk/labltk code is not (due to a large number of tables to handle callbacks). But gtk's re-entrance may come handy at some other time. Cheers, Jacques Garrigue --------------------------------------------------------------------------- Jacques Garrigue Kyoto University garrigue at kurims.kyoto-u.ac.jp JG