Gtk2Hs introductory presentation

The Nottingham FP group invited the two core Gtk2Hs developers (Axel and myself) to come and talk as part of their informal lunchtime seminar series “FP Lunch“. The slides of our presentation are now online along with links to most of the demos we showed off.

We spent much of the afternoon talking to the Epigram group. They are interested in using Gtk2Hs for a new graphical editor for Epigram 2. They want to build a WYSIWYG structure editor with LaTeX-quality on-screen rendering. This is an ambitious goal but not an unrealistic one we feel. We talked about the use of Pango and cairo for text rendering and played with some algorithms for laying out formulae on screen. Code and screenshots of that below. This is an exciting project and one we are keen to see come to fruition.

The presentation

An introduction to writing graphical user interfaces in Haskell with Gtk2Hs

You may find that you need to resize your browser window to be a bit taller and thinner to make sure that the text all fits. Since some people asked: the presentation uses a simple open-source xhtml presentation system called S5.

Of course the slides are rather terse in comparison to the live presentation. We do hope to write some more detailed introductory tutorials at some point. Volunteers to help with this would be most welcome!

The demos

We showed off 14 demos. Some were simple little ones from the Gtk2Hs demo collection, others were bigger programs written by various authors.

Calculator

[img]

This little calculator demo shows off the fact that we can separate the logic of a program and its GUI quite neatly. The GUI part is quite short; it just loads the UI from a glade file and connects up the buttons to functions on the underlying calculator model.

Bitmap graphics and animation

[img]

In the presentation we explained a little about vector graphics with cairo. This demo shows that we can also do raster or bitmap style graphics. Gtk2Hs provides an interface to Pixbufs via GHC’s mutable array class MArray. In the live demo the bitmap animates. On the laptop we used for the demo it ran at approximately two hundred frames per second.

Cairo clock

[img]

We showed off the cairo clock demo. You can see more about that here.

SourceView

[img]

The SourceView demo shows the use of the SourceView add-on for Gtk. It provides an extension of the TextView widget but with extra source code editing features and in particular syntax highlighting. It uses regex-based language description files to do the highlighting. These language files are in an xml format. This demo shows the syntax highlighting of Haskell source code (the code of the demo itself). There are many language description files already for various programming, scripting and data files. This provides a very easy way of doing syntax highlighting.

MozEmbed

[img]

This shows an example of the Mozilla rendering engine in a Gtk widget. This can be useful to embed in certain kinds of applications. For example it is used in hIDE (see below) for displaying html help files. Html provides quite a rich and flexible presentation system and some applications use the technique of generating html to display in an html widget rather than doing the layout with Gtk widgets or custom drawing.

SVG

[img]

This demo shows how easy it is to draw and transform SVG pictures. The code for this demo is very short, it just loads up the .svg file and then scales it to fit the current size of the screen and renders it in the cairo Render monad.

Memory card game

[img]

This is a screenshot of Kenneth Hoste’s “memory” card game. It has a relatively simple UI using buttons with images in them. The code accompanies Kenneth’s introductory tutorial which appeared in first issue of The Monad.Reader.

ICFP ‘04 ants simulator

[img]

I was part of the team that won the 2004 ICFP programming contest. When we won we were proud to say that we did the whole thing using Haskell but were rather embarrassed to admit that our simulator and visualiser were and order of magnitude or so worse that those written by the teams which used C/C++/Java. So after the competition I went back and re-wrote the simulator and visualiser for all out speed. This is a screenshot from that new visualiser. The old visualiser would take several minutes to run for a few hundred rounds or so. This new visualiser runs the whole 100,000 rounds in under a minute. It pays careful attention to minimise the amount that has to be redrawn and to minimise the number of graphics operations that require round trips from the X server. For example it preallocates all the server-side graphics resources that it will need (eg graphics contexts). Then all the following graphics operations can be one-way commands which are then very quick. This attention to client/server issues also has the effect that the program runs very fast even over remote X connections. It is the high latency of network connections that makes remote X slow rather that limited network bandwidth. So by eliminating most or all round trips to the X server we can make X11 GUIs fast even over remote X connections.

Oxford FP practical

[img]

This program was used for a first year functional programming practical at Oxford. It’s described in more detail here.

[img]

This second picture shows a version of this GUI using cairo. Sadly the cairo version could not be used for the practical since the Solaris 9 machines that were used only had a very old version of Gtk+ installed that did not support cairo. So a version was used that used the Gdk graphics API instead. You can also see in this second picture that because we’re using a newer Gtk+ version we have access to widgets like the colour picker button (with transparency!) rather than having to use three spin entry boxes.

3D L-System viewer

[img]

For the same practical next year I hope to allow the students (as an optional part) to extend their L-System programs from 2D to 3D. This is now possible since there is OpenGL support in Gtk2Hs. More on that here.

Cairo L-System veiwer

[img]
[img]

Paolo used this L-System example as a testbed for his cairo binding. He later extended it to allow several productions for each symbol with attached probabilities. This can produce some very pretty results.

Type-inference constraint visualiser

[img]

This is a GUI I wrote for a research project. It helps to get some intuition about large sets of equations that are produced from certain kinds of type inference algorithms. It generates graphs and calls out to Graphviz which generates an image of the graph which the GUI then displays. The GUI also allows individual constraints to be edited/deleted and for simplification functions to be applied to the constraint sets. The GUI is built partly statically from a glade file and partly dynamically from a list of named constraint set transformation functions. This makes it quick and easy to experiment. This was not a difficult GUI to build, it was just thrown together as needs dictated. In many cases, building GUI programs is sufficiently quick and easy that they can be used in little one-off projects like this.

Pivotal

Pivotal is a application being developed at the University of Kent at Canterbury as part of a research project. It is a prototype of document-centred presentation of Haskell. It makes quite extensive use of the text and graphics rendering systems in Gtk2Hs.
More on Pivotal on this site and on the Pivotal home page including lots of screenshots.

hIDE

[img]

hIDE is a Haskell IDE that is currently in development. Unlike other recent Haskell IDE projects that add Haskell support to existing IDEs written in and for other language, hIDE is written wholly in Haskell. This provides a few advantages. For one thing there are no hassles with interfacing Haskell code with COM, .net or Java code. By providing a Haskell plugin API it makes it relatively easy to integrate existing Haskell libraries and tools. For example the current prototype uses a modified version of GHC’s lexer to do syntax highlighting. This makes use of Gtk’s sophisticated TextView widget which supports marking spans of text with various attributes including text colour and underlining. Using a proper lexer gives more accurate syntax highlighting than can be achieved with the regular-expression-based highlighting engine used in many editors (including the SoureView widget mentioned above).

[img]

The current hIDE prototype also uses the GHC API to check syntax and types interactively as you edit the code. It runs the GHC front end in a Haskell thread so it doesn’t interfere with editing. Errors are reported in a message panel and also by underlining the offending part of the code with red squiggles. Again this is making use of Gtk’s rather flexable TextView widget.

[img]

There is also an experimental hIDE plugin to display html documentation. This uses the MozEmbed html rendering widget.

Epigram and formula layout

[img]

Axel hacked up this demo to illustrate the difference between “logcical extents” and the “ink extents” of a layout of text. The ink extents is the rectangle bounding the part that is actually drawn. The logical extents are what you usually use for positioning text because it includes the appropriate padding above and below the text.

[img]

It also shows off Pango’s subscript and superscript features. The exact meaning of the Pango markup string is described here.

[img]

I hacked up this demo on the train to Nottingham. It’s a first go at doing LaTeX-style formula layout. It uses a system of nested boxes to allocate sizes and positions to elements in the layout. The nested box system also allows for efficient intersection testing which in turn should allow for efficient redrawing. In this screenshot you can see that to help with understanding and debugging the box layout system I’ve added red outlines around each box. You will also notice that there is no centring going on; we will want the “data” string to be aligned in the middle of the space it has been allocated. The basic algorithm is to bubble up size information from the bottom and then to propagate position information down the tree of nested boxes. It is during this second phase that we would do things like aligning boxes when they have been allocated more space than they requested. When we finally have figured out the absolute positions and sizes of each box then we can draw them.

4 Responses to “Gtk2Hs introductory presentation”

  1. Peter Moulder Says:

    Re formula layout, please consider using existing code, such as libgtkmathview (or *TeX, depending on what properties you’re looking for). At the very least, read the 2004 guadec paper (see the Documentation sidebar at http://helm.cs.unibo.it/mml-widget/), which mentions some issues you’ll run up against. It also gives the layout of gtkmathview’s source tree.

  2. Immanuel Normann Says:

    When I read about “Epigram and formula layout”:
    “They want to build a WYSIWYG structure editor with LaTeX-quality on-screen rendering.”
    I wonder whether you have already noticed TeXmacs? To my knowledge there is nothing comparable to TeXmacs. To have something like TeXmacs implemented in Haskell would be great! - and I would like to contribute in such a project.

  3. Duncan Says:

    Immanuel, I suggest you email the Epigram people and see if they have any code available. When I talked to them they were quite positive about the idea of sharing any layout/rendering stuff that they might come up with.

  4. Dan S. Says:

    I unfortunately cannot provide a citation, but several years ago I recall reading a paper where someone set out to reproduce Knuth’s formula layout algorithms in O’Caml — if I remember correctly. Should make for easy cribbing/porting!

    Whoops, about that citation. Here you go:
    http://citeseer.ist.psu.edu/heckmann97functional.html

    Cheers!