Gtk2Hs

This is a picture of Kenneth Hoste’s HaskLS 3D LSystem viewer.

In the live program the tree rotates on a vertial axis and looks quite impressive.

The picture above is of HaskLS ported to use Gtk2Hs’s OpenGL support rather than the GLUT. Originally it used a combination of Gtk2Hs for the LSystem settings part of the GUI and HOpenGL with GLUT for the 3D part.

That solution was not optimal since the GLUT and Gtk+ event loops do not run at the same time. The new version works much better and gives the opportunity to embed the widget showing the 3D animation in the main window rather than them having to be seperate as was the case when using GLUT.

Just for fun I’ve got a flash video of the tree rotating. I recorded it using vnc2swf.
(more…)

Here’s the early results of an OpenGL binding for Gtk2Hs:

You can’t see from the screenshot but in the live program the cube spins about.

I’m using the OpenGL extension for Gtk+ called GtkGlExt. This only takes the place of the GLUT, we still use the existing HOpenGL binding for all the actual OpenGL stuff.

The code for the above example was adapted from Kenneth Hoste’s RotatingCube example (which he adapted from somewhere else).

The ‘gtkglext’ package is now included the development version of Gtk2Hs if you want to try it out.

darcs get http://haskell.org/gtk2hs/darcs/gtk2hs/

Another idea for improving the tree/list stuff would be to allow the data model to be defined in Haskell. That way one would not have to make do with the two models provided by Gtk+, the TreeStore and the ListStore. These are rather cumbersome to use from Haskell since it all has to be done in the IO monad. Also it doesn’t feel ideal since you’re having to stuff your data into a different structure rather than just providing an adaptor for your existing data model.

Now the Gtk+ tree/list system is designed to follow the model/view/controller pattern so it does allow you to create your own models that implement the GtkTreeModel interface. However Gtk2Hs does not provide a way to implement the GtkTreeModel interface using Haskell. So my suggestion is to do just that.

I’m not quite sure how this would pan out but I think it’s worth a go. It can’t be worse than the existing system!

This would be implemented by writing in C a HaskellTreeStore that implementes the GtkTreeModel interface and deligates its implementation to a Haskell implementation. The Haskell implementation would probably be an instance of some new type class, lets call it TreeModelInterface.

So suppose you have some data and you want to connect it up to a list widget.

data MyDataset = ...

Then you would need to make it an instance of the TreeModelInterface

instance TreeModelInterface MyDataset where
  getNumberOfRows mydataset = ...
  getValue mydataset row = ...
  ...


Then if you’ve got a value of your MyDataset type then you could construct a TreeModel:

treeModelNew :: TreeModelInterface model => -> TreeModel

So you would then connect this new model to a view in much the same way as one currently does with the TreeStore and the ListStore models.

These names are not the greatest, just the first thing I thought of, suggestions welcome.

Duncan has pointed out that we’d like to re-implement my Mogul stuff for creating tree/lists widgets, hopefully using a more Attr-like style. The problem with the current Mogul stuff is that it provides constructors that return functions to read and write the cell values. Each pair of read-write function has a type that corresponds to the data stored at the specific column. Although this is very object-oriented, it means you have to keep two functions around for each column in the tree model. This is a pain since the read and write functions have to be passed to every function that manipulates the list/tree. It would be more convenient if phantom types or type classes could be used to ensure type-correct access. This is very appealing since the (type of the) columns of a tree model must be static anyway.
(Note that this does not mean that the set of columns that are shown is static; what columns are visible is determined by the view, not the model.)

Here is the framework:

• a visible column is drawn by a cell renderer
• each cell renderer has several attributes, e.g. the text of the cell and the foreground colour
• while the foreground colour attribute can be the same for all rows, some attributes (like the text) should be different for each row; these changing attributes are retrieved from the model
• the model contains a column for each of the changing attributes, and several rows that make up the actual data of the list or tree

What we aim for is a type-safe interface to access the different columns in the model. As mentioned above, the set of columns in a tree model are determined at creation time. One idea I had was to use a nested phantom type to represent the types of the columns. For example, a model that contains two String columns and one Pixbuf column could have the type

TreeModel (Column String (Column String (Column Pixbuf ())))

where Column is some empty newtype constructor. One problem I see with this approach is that accessing the nth column cannot be expressed. Instead one would have to define function to read or write a specific column, e.g.

readFirst :: TreeModel (Column val a) -> IO val

readSecond :: TreeModel (Column a (Column val b)) -> IO val

which obviously imposes a hard limit on the number of columns a program could defined. Suggestions welcome.