What are the relative merits of wxHaskell and Gtk2HS?

Question

Which is better for developing GUI applications with Haskell, wxWidgets (via wxHaskell) or GTK (via Gtk2HS)?

What are the pros and cons of each? Does it vary depending on which platform you are targeting (I would primarily be working on OS X but would like my programs to work on Linux and Windows too)?

Barely

Answer 1

[Disclaimer: I am a wxHaskell maintainer]

Both are stable and fairly complete GUI bindings, and you could choose either for most projects with confidence. Both have some degree of 'higher-level' Haskell bindings, but in both cases you will need to drop into rather imperative 'C' style coding to get things done. My impression is that wxHaskell allows you to spend a little more time in the higher-level bindings, but I've not done much GTK2HS, and in any event, you definitely find yourself working on the thin end of the wrapper for both libraries - and I think the overall programming 'complexity' is similar in both cases.

Therefore, let's take the basic functionality as a given and concentrate on the differences. Please note that I genuinely believe that GTK2HS is an excellent piece of work, and that you will be happy if you choose it. Most of what I say below is a personal take on the differences, and why I choose to work on and with wxHaskell myself.

GTK2HS has a larger team working on it, and is released more regularly. wxHaskell is not updated as frequently, but the core team is active, and there are regular bugfixes, but with major new functionality being added rather more slowly than we would like (we all have day jobs).

wxHaskell gives true native application appearance on all supported platforms out of the box. GTK2HS is, of course, native on Linux and has a pretty good native theme on Windows (i.e. good enough to satisfy all but pedants...), but has GTK look and feel on OSX, and depends on having X11 installed. I believe that an OSX 'native' GTK library is under development, but is considered relatively immature. Once this is stable, GTK2HS should be able to easily benefit from the same 'partially native' look and feel (e.g. GTK OSX screenshot).

wxHaskell is probably a little easier to build if you are not on Linux (GTK2HS is likely easier if you are Linux hosted), but both are pretty complex to build, to be honest, as there are a significant number of dependencies in both cases.

It is slightly easier (IMHO) to distribute applications based on wxHaskell, simply because it has fewer library dependencies. I distribute applications using mainly InnoSetup on Windows, and as App bundles on OSX. I would admit that with only a small amount of extra work, the same could be done with GTK2HS, so this is probably the weakest argument in favour of wxHaskell.

It is my personal opinion that wxHaskell is friendlier to closed source (e.g. commercial) developments. This is, of course, the subject of interminable flame wars, so I will only say that wxHaskell is under the wxWidgets license which unambiguously allows for closed source development. GTK2HS is LGPL, so you'll need to ask your lawyer - although I must make it clear that many people and companies have concluded that LGPL is compatible with commercial development; the lawyers at the company I work for have concluded that it is inappropriate for our projects.

I think that if Linux was my main development and delivery platform, I'd probably use GTK2HS. It isn't, however: I deliver mainly to Windows with occasional OSX, and I think wxHaskell is a better match to these platforms, although both options support all three platforms.

I hope this will help you with your choice.

Handcar

Answer 2

A consideration is that currently it is slightly easier to get wxHaskell to work natively on Mac OS X. GTK2HS depends on GTK, which does have an implementation using native widgets on Mac OS X, but that implementation is not as easily built as the wxWidgets implementation for Mac OS X is.

Therefore, if you want to develop code to run without X11.app, currently you are slightly better off with wxHaskell.

Note however that this is quickly changing: http://www.haskell.org/haskellwiki/Gtk2Hs#Using_the_GTK.2B_OS_X_Framework shows how to use GTK2HS with native GTK+ on Mac OS X.

One advantage of GTK2HS is its GLADE support, making the development of simple UI very quick. The higher level combinators in wxHaskell mitigate most of that advantage, but they do require a deeper understanding of how you want your interface to look and behave, and therefore are harder to use in an exploratory fashion.

Wallasey

Answer 3

I have pretty incomplete information, but since you have no answers yet, maybe incomplete information is better than none.

The question to ask is this: is the toolkit just a wrapper around C-like functionality, or is there an additional layer that gives the toolkit a more "native Haskell-like" API? When wxHaskell was first announced at the Haskell workshop, the development of the native Haskell API looked extremely promising, but was still incomplete. It looks as if the "Haskellized" API for wxHaskell is still being worked on, whereas the Gtk2Hs project doesn't mention this issue at all. For that reason I'd recommend wxHaskell.

Informal

Answer 4

Personally I would look into some sort of Reactive package/extension. It seems to sit with the paradigm much much closer. Instead of specifying your graphical stuff imperatively, you can do it declaratively. Example (not representative of any particular language or implementation):

x, y, z              :: Int
click, buttonclicked :: Bool
x = <X coordinate of mouse>
y = <Y coordinate of mouse>
click = <Whether mouse button is currently being pressed>
z = x + y
buttonclicked = (x == 10 && y == 10 && click)

Buttonclicked and z will be automatically updated every time x and y change.

You could then have some logic somewhere that looks something like this:

if buttonclicked then <do something> else <do something else>

This is all very fuzzy though. Just look into some real reactive interfaces

Hough