From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 908F1820A1 for ; Thu, 12 Sep 2013 00:03:53 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of garrigue@math.nagoya-u.ac.jp) identity=pra; client-ip=133.6.130.5; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="garrigue@math.nagoya-u.ac.jp"; x-sender="garrigue@math.nagoya-u.ac.jp"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of garrigue@math.nagoya-u.ac.jp) identity=mailfrom; client-ip=133.6.130.5; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="garrigue@math.nagoya-u.ac.jp"; x-sender="garrigue@math.nagoya-u.ac.jp"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mailhost.math.nagoya-u.ac.jp) identity=helo; client-ip=133.6.130.5; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="garrigue@math.nagoya-u.ac.jp"; x-sender="postmaster@mailhost.math.nagoya-u.ac.jp"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUEAGjoMFKFBoIFdGdsb2JhbABbFoMpwFiBMw4BDBUIPIIlAQEDAQFDATUCAwsLGC5JAQ0GExQHh2EFAQysYoRSAoU+iE0HjzczB4MdgQCJOI5Ehi+OdA X-IPAS-Result: ArUEAGjoMFKFBoIFdGdsb2JhbABbFoMpwFiBMw4BDBUIPIIlAQEDAQFDATUCAwsLGC5JAQ0GExQHh2EFAQysYoRSAoU+iE0HjzczB4MdgQCJOI5Ehi+OdA X-IronPort-AV: E=Sophos;i="4.90,887,1371074400"; d="scan'208";a="32500430" Received: from rabbit.math.nagoya-u.ac.jp (HELO mailhost.math.nagoya-u.ac.jp) ([133.6.130.5]) by mail2-smtp-roc.national.inria.fr with ESMTP; 12 Sep 2013 00:03:50 +0200 Received: from mailhost.math.nagoya-u.ac.jp (localhost [127.0.0.1]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTP id A291E63AD; Thu, 12 Sep 2013 07:03:48 +0900 (JST) Received: from mailhost.math.nagoya-u.ac.jp (localhost [127.0.0.1]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTP id 1052A2504; Thu, 12 Sep 2013 07:03:48 +0900 (JST) DomainKey-Signature: h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=; c=nofws; d=math.nagoya-u.ac.jp; q=; s=alpha Received: from [10.5.33.220] (O-TK-MSC52000001.w-lan.jp [143.90.238.110]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTPSA id 84D7424F7; Thu, 12 Sep 2013 07:03:36 +0900 (JST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Jacques Garrigue In-Reply-To: Date: Thu, 12 Sep 2013 07:03:19 +0900 Cc: OCaml Mailing Content-Transfer-Encoding: quoted-printable Message-Id: <843DB424-8563-45A7-A22A-2FA65338298B@math.nagoya-u.ac.jp> References: <20130910230928.2d51cd39@atmarama.noip.me> <20130911052437.GA9514@notk.org> To: David MENTRE X-Mailer: Apple Mail (2.1508) Subject: Re: [Caml-list] OCaml vs Ada and/or GUI options Hi David, I know you just wrote this list as a kind answer, but I cannot resist givin= g my view :-) On 2013/09/11, at 18:49, David MENTRE wrote: > 2013/9/11 Adrien Nader : >> I'm trying to get a list of things that people find bad in (labl)gtk. >> Would you be able to put clear words on what you dislike? >=20 > From past experiment, GUI of demexp OCaml application > (http://www.linux-france.org/~dmentre/demexp/latest-src/demexp-book-0.8.2= .pdf > , look at part IV p. 90), about 5-8 years ago: >=20 > 1. Lack of documentation. LablGTK doc says "look at C GTK doc". But > the lablgtk binding changes things compared to the C API, so this not > a one-to-one mapping neither. And the "obvious" changes weren't so > obvious to me. A tutorial made by a Korean guy IIRC helped a lot; I'm certainly the one to blame for that. If Adrien can improve that, big th= anks to him. Still, the concept for LablGTK was: provide access to the GTK+ API, but red= uce the cruft. So, it is type safe with (almost) no need for coercions, and pac= king can be done on the same line. Ideally this should have been close to LablTk, but GTK is much more complex than Tk. > 2. Verbosity of GTK: it takes a lot of code to put 2 buttons > together (probably not GTK specific). At one point I used the GTK > graphical tool (can't remember its name) to design the GUI graphically > and load it into OCaml as XML file. It improved a lot my productivity; Cannot blame you for that. Actually this is the right way to go if you have= little time. Unfortunately, this makes code harder to maintain. As Adrien pointed, even written by hand LablGTK is much shorter than its C = equivalent. A ratio of 1/3 at least. > 3. As other said, GTK is dead end: bad support of non-Linux > platforms, not a lot of developers, etc. It was very difficult to get > my labgtk application working on Windows. A windows developer helped > me a lot: picking the good versions of libraries, solve Windows > specific issues, etc. I couldn't have compiled my OCaml GTK GUI on > Windows without him. I'm a bit surprised, as I never had problems on windows. More honestly, there is one problem: where to find the packages. But once you got them, it works just fine. On the other hand OSX support seems to be never completed. A pity. > 4. The use of callbacks everywhere looks to me like writing > spaghetti code. I still hope somebody will write an > API/Framework/whatever were one writes declaratively how the GUI > should react and interact with application code, and all the needed > code is generated automatically. Adobe had such a tool at one point > for its internal use (i.e. for its applications). I don't know if > reactive approaches would help in that regard. I would rather say that this looks like OO code :-) I have no allergy to that, and OCaml allows you to write in a much cleaner way than C. However, this is clearly not declarative. There are lots of experiments about declarative GUI in the Haskell community, but I have no experience on how it fares in practice. BTW, lexifi has also some internal system to build GUIs automatically. I don't know if there is a blog post on that. > To answer original Gour question: I don't think anything in the OCaml > world fits the bill (safe, available at long term, documented, big > user community, ...). Should I do the same thing, I would write the > GUI as an external process (probably in C++ Qt) and use a > communication protocol to control it from my OCaml program. Or maybe > use the binding with Tk, if the graphical aspect has improved. For Tk, I wouldn't say that the graphics have improved much. And LablTk may not support the latest features. Still, of course we can improve it, and comments are welcome. But don't expect anything professional. I agree that support for Qt would be ideal, and I actual first worked on a LablQt before starting LablGTK, but writing bindings is much harder. With all its defaults, GTK was designed with other languages in mind, and this makes a huge difference. In theory, with the latest versions one should be able to generate the bindings completely automatically (but this is still experimental in LablGTK). Also, every time I talked about improving LablGTK, I have gotten comments about GUIs being web-based these days, so that generating JavaScript would be the way to go. Are there good solutions for that? Jacques Garrigue=