I'm looking for recommendations (testimonials?) for GUI libraries for
haskell (ghc 6.5) on the win32 platform that meet my requirements
below. But first, I try to motivate my question.
Bit of background:
I work at a smallish software company and I've been given a project
where I'm supposed to create a prototype which will later be scraped
and a new version will be written that is part of our main product.
The prototype will only ever run on windows and it will be distributed
to customers for a year or two before it is assimilated.
I've used python a bit to prototype the prototype and figure out some
of the basics. I'll need a small GUI (maybe one or two dialogs), an
XML library, a few small parsers and COM support. I was going to put
Haskell back on the shelf and use either python or scala for this
project because of the COM requirement but just today I made a major
breakthrough with H/Direct and it looks like Haskell is back in the
running. So far I plan to use HaXml, parsec and H/Direct but I still
need some way to create a gui.
This project is fairly representative of all the work we do at my
company so I feel if I find a good solution this time it's probably
what I'll focus on using in the future. That's part of the reason I'm
trying out python, Haskell and scala. (Perhaps the real reason is just
that I like playing with languages ;).
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)
I don't really know the landscape, but this is my (uneducated) idea of
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
I think that (C) is going to violate #4 and maybe #3 depending on how
much code I need to write to get the bare windows api to do what I
want. Plus I doubt this makes sense for a long term solution.
I think (D) makes less sense than (C) and I doubt it's a nice way to
do things, I'm probably better off with (C). As for (E), why don't I
just do the whole thing in scala if I'm requiring the GUI to be in
> 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.
can't you ask library maintainers to compile their libs for ghc 6.5. it
should come out in several months and i think it's the time when
library maintainers can start to check whether new ghc version can
work with their libs
On 6/26/06, Bulat Ziganshin <[hidden email]> wrote:
> Hello Jason,
> can't you ask library maintainers to compile their libs for ghc 6.5. it
> should come out in several months and i think it's the time when
> library maintainers can start to check whether new ghc version can
> work with their libs
Ah, good idea. It never occured to me. I'll have to ask the wxHaskell
As far as I am aware, the Win32 bindings are not that well maintained
currently, and programming against the Win32 API is quite painful
since it is a very low level, and very C like API.
Gtk2Hs does require additional dependancies, but seems to be the most
actively developed version. When a friend of mine was doing GUI
development work in Haskell he found that having all the Gtk2Hs
maintainers on the haskell IRC channel meant he could get advice and
fixes really really easily.
As for the additional dependancies, which Gtk2Hs definately does have,
there are plenty of "exe packers" which will take an executable and
all its dependancies and bundle them into a single .exe. I guess using
this any option would pass 1.
As for 2, I found wxWindows to be more native feeling that Gtk2Hs, but
Gtk2Hs is reasonably close so its not the end of the world.