Hi Jason.
My $0.02
On 27/06/06, haskell-cafe-request@haskell.org
---------- Forwarded message ---------- From: "Jason Dagit"
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