Arrrgghh writing GUI programs is tedious

Last week I thought it would be a good idea to write a small GUI front end to virt-resize.

After two days, I nearly have the first tab (out of four) working.

Granted, maybe the first tab is the hardest one:

The job of the first tab is to ask the user for the source (disk image or libvirt guest). It then fires off a background job to open that guest and inspect it for operating systems. Based on the outcome of that (opened OK, found OSes, no OSes found, etc) it has to update and enable the other tabs.

Also the user can preselect a guest on the command line. We also have to deal with connecting to libvirt asynchronously to read the list of guests (and this might also fail in a number of ways).

So far, 1600 lines of code, and the first tab is by no means complete.

One part of the problem is there’s a certain “impedance mismatch” between functional programming in OCaml and writing Gtk. Gtk is heavily mutable and object based. OCaml prefers (but does not require) immutability, and objects in OCaml are obscure and not widely used, and the Gtk bindings are written in a very hard-core object OCaml style.

Another part is just that it’s tedious. It would be tedious if I was doing this in C or Python too. You’ve got asynchronous actions going off here and there which update bits of state. Every control or input could potentially affect every other control or output, resulting in a kind of O(n²) mess of wiring up signals and callbacks.

Is there an easier way? I don’t know …

Concept for a graphical libguestfs browser

This is a concept for a graphical guest filesystem browser, a GUI guestfish if you like. Click the images for full sized versions:

The tabs correspond to mountable filesystems. The leftmost “Filesystem” tab is currently empty — originally I wanted to put the VM filesystem there with all individual devices mounted in the right place, but that’s quite hard to implement. I might use that tab for partition/LV operations, or just drop that tab.

It uses multithreading (via message passing) to hide the latency accessing filesystems. Lablgtk2 is used for Gtk access. The whole program is just 1,500 lines of OCaml at the moment. You can have small and fast and safe, if you stick your head out of the C / slow scripting language world for one minute.

Dear Lazyweb, how do I put buttons in a Gtk Menubar?

Tech Talk PSE needs a better menu bar:

+----------------------------------------------------+
| [Next slide] [Prev slide]  ...  [ V More Options ] |
+---------------------------------|                |-+
                                  | First slide    |
                                  | Last slide     |
                                  | Slides       > |
                                  |                |
                                  | Quit           |
                                  +----------------+

But how do you do this? It seems like either I want to put a regular button into a GtkMenuBar, or else put a drop-down menu button into the GtkButtonBox that we currently use to hold the next/prev buttons.

I can’t make either of these work …

Learning Functional Reactive Programming

Functional Reactive Programming (FRP) is a programming technique that I think hasn’t filtered down to the level of workaday programmers (like myself) but is well-regarded in the academic community.

Upside is that it could make writing Gtk and web applications much simpler.

Downside is that no one from the academic world has ever managed to explain FRP in a way that makes any sense to mere mortals. There are, as far as I can see, no good tutorials about FRP on the web, and by “good” I mean to exclude any that mention words like “composition”, “point-free”, “point-wise”, “denotational” or any other jargon like that.

Well, this one isn’t too bad … What I really need though are real, concrete, compilable examples.

The inimitable Daniel Bünzli, author of the OCaml FRP framework React wrote his own intro to FRP today, although I’m still not convinced I understand it.

So I’m going to learn it, and if I can, describe it to you in some forthcoming posts.

But what everyone agrees on are the basics: FRP is about putting the imperative programming concept of a “variable” on a sound theoretical basis. Let me explain …

In C you can declare a variable, like:

#define UP 1
#define DOWN 2
int mouse_button_state = UP;

and you can assign to that C variable over the course of your program:

void button_pressed (void)
{
  mouse_button_state = DOWN;
}

The problem[1] is that mouse_button_state changes as time passes, but the variable itself doesn’t capture the past, present or future of the variable. Assigning a new value to the variable (a) doesn’t record the time that the variable changed, and (b) obliterates all previous states of the variable. The variable has no memory of what happened before.

[1] I’m using the word “problem” advisedly here. You and I might not think this is a problem at all. But FRP is going to persuade us that this is a problem and by putting variables on a sounder theoretical basis, our programs will be shorter and easier to reason about.

C programs that really deal with mouse events are, of course, full of callbacks. When a mouse button changes state (or more often, when it changes state several times) we want to call back some function that takes an action in response to user input. Callbacks are a huge problem in imperative programs, as you’ll know if you’ve ever done anything non-trivial. Amongst the problems are (1) they run asynchronously, (2) they run in some other part of the program and it’s not obvious what runs when and where, and (3) they often have bad interactions when several callbacks run and they might be called in different orders.

FRP promises to fix this, again by modeling events on a sound theoretical basis.

FRP also promises to save us from reasoning about: complicated multithreaded programs, event-driven programs (like operating systems, libvirt, etc.), writing web applications, and writing GUI applications.

I’m yet to be convinced, but I’m going to learn about FRP and try to write the world’s first usable FRP tutorial.