Re: [Caml-list] Desktop GUI toolkits - current state of the art?

[Adrien <camaradetux@gmail.com>]

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