(Click to enlarge if WordPress.com squashes the image)
What I learned yesterday:
- Programming Gtk apps is horrible. Gtk leaves far too much fiddly detail up to the programmer, and doesn’t have sensible defaults.
- Programming Gtk apps with OCaml has an impedance mismatch (Gtk is imperative and highly mutable, OCaml is functional and mostly immutable). Luckily this isn’t Haskell, so we can drop into mutable code when we need to.
- Programming with threads and locks is time-consuming for even the simplest things.
- On the other hand, it is possible to write a decent multi-threaded app which accesses libvirt and libguestfs and leaves the user interface responsive. Here is a proof by existence of that.
The code will appear in The code is available here.ocaml/examples in the libguestfs source repo shortly.
Exercises for the programmer:
- Display the mount point of each partition.
- Double click on partition to display the tree of files inside.
Richard WM Jones 
Every graphics system I’ve ever used is event driven, which the imperative, mutable OO model just fits well in. Or have you used another system that you’re contrasting with GTK+?
What defaults did you find fiddly?
Imperative and event driven is by no means the only way to do it.
Another way is to use “control inversion” to turn events into long running functions. These are much simpler to follow because control flows naturally through the function. In such systems [I wrote one] you can write:
f () { button_pressed = display_ok_cancel_buttons (); if (button_pressed == OK) { ... } }Continuation-passing style is another way, extensively used in LISP, which is similar to the above.
A third way is Functional Reactive Programming. The Haskell guys have a whole selection of GUIs built in this style to choose from. I can’t find a good intro to this, but perhaps you can read this paper on genuinely functional GUIs.
In any case, using OCaml and Gtk together isn’t necessarily a problem – OCaml has better OO support than most OO languages, and we can use mutability when we need it. I find writing Gtk interfaces in any language a big pain. It’s far harder than writing a command line interface, but shouldn’t necessarily be so. Yet so far no one seems to have found the silver bullet to make it easy. Tcl/Tk was the last language where I actually enjoyed writing UIs, although Tcl as a language had its own serious limitations, and Tk has been going nowhere for years.
I looked at the Haskell FG-GTK+ example, but at first thought I was looking at an entry in the Obfuscated Perl contest 😉
I agree though OCaml’s ability to drop to mutability makes it very practical, way back in the past I wrote lablgtk apps as well.
It looks like your toolkit is for server-side generated HTML web pages? Which is quite different from client-side “traditional” GUIs. Most “traditional” GUIS involve are less modal/or page->page->page oriented, in other words you’re presenting a bunch of interaction controls and need to handle events on all of them at the same time, and I don’t see how control inversion ends up workable there.
The point of the control inversion was to turn HTML into something stateful. In Monolith, you could place widgets on a page and have those widgets react just like a traditional GUI.
At one point we had a calculator demo with four calculators arranged like this, with fully working buttons:
On the client side it was all done in plain HTML (ie. no Javascript). Which is one of the reasons why Monolith doesn’t matter now – if you were doing it now you’d use Javascript and async callbacks to a web server.
But anyway, this is getting off topic …
Taking a cheap shot at Haskell, eh? 😉
Well, you know Haskell guys, instead of just dropping to imperative programming, the find nice elegant ways to abstract the details. But you knew that already. no?
See the comment above. I would at least like to see Haskell settle on one FRP framework.
I think it will happen. Eventually someone in the haskell-platform group will bite the bullet and pick one framework for the platform.
Too bad RH is so GTK+-centric… If you want to try out an actually easy to use UI toolkit, you should really give Qt a try. And I recommend using the kdelibs as well for non-trivial apps.