From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id C0A65BC57 for ; Sun, 28 Nov 2010 23:20:23 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar8BAOZj8kzRVde0kGdsb2JhbACicwgVAQEBAQkJDAcRAx+nWIlkghiEDC6IVgEBAwWFQgSKYYYB X-IronPort-AV: E=Sophos;i="4.59,272,1288566000"; d="scan'208";a="68205081" Received: from mail-ey0-f180.google.com ([209.85.215.180]) by mail3-smtp-sop.national.inria.fr with ESMTP; 28 Nov 2010 23:20:23 +0100 Received: by eyf18 with SMTP id 18so1512235eyf.39 for ; Sun, 28 Nov 2010 14:20:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=1b2G2HK4UnUJlpiLAsCTeNnVweD/451gGBkh8Cr5f08=; b=vv4AP5hZpYjUpnX7WgIlraP5GOEIX2SeNM8+c81aqx3v2+nbKZB5RJdnVoGIyNvcd0 KRaDeZgxje7OURQzCEPvvtF2wHbXy+fU2FYiNA4502YROB7MYiAKAaHELxV80HDe/yIq XCWRfZQpTON8wH4vxdwO+LZgfGpBEW0ciaCAI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=fvDWYT2B6fXy/Xaj8b77w7vc2y6/laTZkGy5i0NwJRqZGyzYFV4GI7AwHj1As8wNkc lV6VM7DWL/q4rpY9VVjYSL+AW4wXw935laa2qLwGcbgrGI7B5wN1M7PSU7jW81SsqWxj G+PvQ33C3/GTS0HiOG2W+Hu6reOIl6mNwxuL4= MIME-Version: 1.0 Received: by 10.213.26.74 with SMTP id d10mr496668ebc.61.1290982822549; Sun, 28 Nov 2010 14:20:22 -0800 (PST) Received: by 10.213.16.130 with HTTP; Sun, 28 Nov 2010 14:20:22 -0800 (PST) In-Reply-To: References: <4CEC4EF0.30805@lexifi.com> Date: Sun, 28 Nov 2010 23:20:22 +0100 Message-ID: Subject: Re: [Caml-list] Desktop GUI toolkits - current state of the art? From: Adrien To: OCaml List Content-Type: text/plain; charset=ISO-8859-1 X-Spam: no; 0.00; gtk's:01 ocaml:01 lablgtk:01 verbose:01 gtk:01 wrappers:01 lablgtk:01 maxence:01 guesdon:01 haskell:01 gtk:01 obj':01 uninstall:01 config:01 imho:01 Hi, As Jacques said, lablgtk's api is close to gtk's one. I also believe that was the best solution/approach. Binding that many C functions to ocaml is already hard enough (not that it could be made easier, the difficulty lies in the number of functions). The drawback is of course that writing code using lablgtk is almost as verbose as writing it directly in C with gtk. Something nice would probably be to share more extensions and wrappers around lablgtk. I've noticed Maxence Guesdon had made some available as stand-alone libraries but I'm not aware of others. Or maybe they're scattered around and it's hard to find them. As far as I'm concerned I've started experimenting with the concept of "tiling" (as used by tiling window managers) and zippers of horizontal and vertical boxes. That's pretty much what xmonad (window manager written in haskell) does. The zipper allows to nicely track the "current" widget. Next in my plans is a wrapper around treeviews/listviews and gtknotebook to map a set of widgets to a list or tabs. And, a last (long) point, a few months ago, I asked on this list about lablgtk and FRP; I ended up doing something myself. It turned out that my "lablgtk-react" is something like 50 lines of code. It's really small and there wasn't much work, once you knew the guts of lablgtk and gtk that is. GTK defines properties and signals. Signals are regular "something happened"-messages and properties are values stored inside objets. Each property also defines a "${prop_name}::notify" signal that is emitted each time the property is modified. This is unfortunately not exposed through lablgtk but the connect_by_name function is enough. Now, you may wonder whether FRP is *that* nice to use. One of the nicest thing imho is the ability to use "fold": let zipper = React.E.fold (zipper x config t) Zipper.empty tabs in This means it's possible to move away from imperative data structures with all their disadvantages. There is currently one issue however: the API is quite bad. install_sgn_event Entry.S.activate address_bar.as_e Signal.apply1 address_bar.activate (* Entry.S.activate is emitted by a text entry upon pressing Return * address_bar.as_e(ntry) returns the 'Gtk.entry Gtk.obj' because * its's not possible (yet) to use the object layer here * address_bar.activate is a potential previous signal handler for * active, we'd uninstall it before install another one *) Ideally, it'll become something like: address_bar#react#activate#event If you want to have a look at the module, I've put it on vpaste.net[1]. It's a bit old and several things have been changed but it still shows how things are done. [1] http://vpaste.net/Vrukn? -- Adrien Nader