[Haskell-cafe] Re: Haskell-Cafe Digest, Vol 34, Issue 45

[Jeremy O'Donoghue]

Hi Jason.

My $0.02

On 27/06/06, haskell-cafe-request at haskell.org
<haskell-cafe-request at haskell.org> wrote:
> ---------- Forwarded message ----------
> From: "Jason Dagit" <dagit at eecs.oregonstate.edu>

> Requirements:
> Okay, so now that you know why I'm here, let me give you an idea of
> what my *ideal* GUI library would be for this project (roughly in
> order of importance):
> 1) Doesn't require the end user to install anything (no dependencies)
> 2) Looks and feels like windows
> 3) Robust (or mature)
> 4) A pleasure to program (boo @ swing)
> 5) ??
>
> I don't really know the landscape, but this is my (uneducated) idea of
> my options:
> A) wxWidgets
> B) gtk2hs
> C) win32 api
> D) write the gui in C or C++ and use the FFI to invoke it
> E) write the gui in scala or java and use FFI + JNI to invoke it
> F) ?? you tell me
>
> I think (although I have yet to verify) that (A) satisfies #1-4, but
> (B) doesn't satisfy #1.  Is this true?  I tried to install wxHaskell
> but it turned out to be a real pain.  I'm using visual haskell so that
> I have COM support (I need the version of H/Direct that ships with
> VisualHaskell and VisuallHaskell only ships with ghc 6.5) and that
> means I have to compile the less mainstream haskell libraries myself.
> I have yet to successfully install wxHaskell on my dev machine at
> work.

I've developed a couple of projects with wxHaskell, along with a
couple using the lablGtk2 library for Ocaml - in fact, the whole
clunkiness and lack of Windows and (especially) Mac native feel of GTK
on non-Linux platforms is a large part of what brought me to Haskell
:-)

My applications are mainly for internal use at my workplace, and come
with Windows installers (I use Inno setup with wxHaskell - never
managed to make it work with GTK2, so these applications were
delivered as zip files which just had to be unzipped in a certain
place).

To distribute wxHaskell applications you need only two DLLs and an
executable. All can be in the same directory. I think this covers 1)

Look and feel is Windows native. As an added bonus (for me, at least)
it also looks native on Mac and Linux. That's 2)

wxHaskell is fairly robust, but you need to be aware that it does not
have complete coverage of the wxWindows library. I have found layout
behaviour to be incomprehensible at times (although I found this to be
somewhat true of the native wxWindows sizers on which layout is
built). Some of the more exotic widgets (Scintilla, wxGrid) are either
not wrapped, or the wrapping is incomplete. I have not succeeded, in
the general case, in getting sash wiondows to work as I would like
them to (it's possible for some limiting cases, but that is not enough
for my needs)

My impression, sadly, is that little development now goes on on
wxHaskell. The last compiled binaries available from the website are
over a year old now and, as you've already discovered, it's really
quite difficult to get wxHaskell to compile on Windows. For what it's
worth, I gave up on 2.6.x and reverted to 2.4.2, which compiled
cleanly for me.

Because of the appearance that it's withering on the vine, I would be
reluctant to recommend wxHaskell. However, despite the gripes above, I
think it's a superb piece of work. I have managed to produce some very
high performance applications with it - users assumed that I had
written in hand-optimized C (FastPackedStrings also had a big hand in
the performance). If the project were better documented, I really
believe that there's a chance that the project would take off. As an
example, I easily have the knowledge of C/C++ needed to contribute,
and the Haskell is getting there, but the (lack of) documentation
makes it hard for the end user at times - let alone the wannabe
developer.

In short, I'm not sure about 3).

wxHaskell programming is something of a mix of Haskell idioms (layout,
in particular) and C style imperative programming (in IO monad). In
some respects the UI code looks quite similar to wxPython, but at
least you get Haskell goodness for everything else. This is a big
plus.

Back in the day when I was using the Ocaml GTK2 binding, the following
observations were true. I suspect they may be true of GTK2Hs (as they
are mainly observations on GTK2 on Windows per se), but I am not
certain.

Installation of GTK2 on Windows is nothing short of revolting. It's a
completely manual set of 'work out which DLL or library to download
from where and install it in a suitable directory. Building from
source is worse.

I never managed to work out a small, sane set of DLLs which could just
be packaged with the executable I was delivering. It may be possible,
but I didn't manage it. That's a fail on 1), I suspect.

Look and feel is adequate on Windows, for the most part. However, the
file dialog, in particular, caused my users (mainly engineers, so
pretty switched on, on the whole) no end of confusion, and was a major
driver to my dropping Ocaml for this type of work. That's a failure on
2), at least for me.

However, in its defence, GTK2 is stable and capable on Windows. I also
have the impression that GTK2Hs is much more actively developed than
wxHaskell, and this may be a good reason to choose it if what you are
producing is a prototype which will not have wide distribution. I
think you'd have to give GTK2Hs a good rating for 3).

I can't really comment on your other potential solutions.

Regards
Jeremy