Hi Daniel, 2009/4/30 Daniel Carrera <daniel.carr...@theingots.org>: > Jeremy O'Donoghue wrote: >> 2009/4/30 Daniel Carrera <daniel.carr...@theingots.org>: >>> 1) First, a broad question: Why do you like wxHaskell? [snip] >> The company I work for has major issues with LGPL (we're flat out >> forbidden to use anything LGPL, although GPL is OK in certain >> circumstances), whereas wxWidgets (and hence wxHaskell) has a license >> that unambiguously allows for closed source development. > > That's very interesting. This isn't an issue for me (my employer is > happy with any FOSS license), but it's interesting anyways.
Flame war material on many lists, but it's my employer's rule (or rather, my employer's lawyers' rule...), so I need to stick by it. >> I like that it is stable, has pretty much all of the features I need >> in a GUI, is easy to distribute (i.e. roll up into an installer) and >> looks good on all three major platforms. > > The "easy to distribute" part is interesting. Is there something that > makes Qt or Gtk harder to distribute? Maybe it's the license... Nothing to do with the license, and all about building an installer :-) Depending on how you build wxWidgets / wxHaskell, you can have just a single DLL to distribute along with your application (the default build creates about 10 DLLs and uses dynamically linked C library, but Microsoft has recently invented a whole new version of 'DLL hell' with the use of Manifest library descriptions. I find it much simpler (i.e. more or less guaranteed to work on any client machine) to build a single DLL containing wxWidgets, C runtime and the wxC bindings (to which wxHaskell talks via FFI). Gtk+ is composed of a very large number of DLLs - it's not too hard to package up, but I've run into problems in the past where more than one Gtk+ application is installed on a machine and the 'other' Gtk+ DLL appears earlier on the path than the correct version. None of this is insurmountable, just tedious to track down and fix if it happens. Worth mentioning that these packaging issues are pretty much confined to Windows targets. Linux and Mac seem to be less problematic, probably because libraries tend to live in a small number of locations and shared libraries can coexist in multiple versions more readily. >>> 2) I've heard that wxWidgets doesn't work that well on Mac OS X, but >>> looking at the screen shots, it looks very native to me. How is OS X >>> support? [snip] >> but it is closer (out of the box) to OS X native look and >> feel than either of Gtk+ or Qt IMHO. > > Qt too? That's interesting. I sort of assumed that Qt would be better on > Mac, but I haven't checked. Later on I'll reboot into OS X and install a > couple of Qt and Wx apps and see how they look. Depends on how critical your users are. Qt and wx are probably fine for all but the most demanding UI zealots. I think Qt has its own (non-native) implementations of a few widgets on Mac, but they are probably avoidable if you really must look native. The latest (native Mac) versions of Gtk+ are getting considerably better, but still have a way to go, and native Gtk+ is not really production ready on Mac as yet, although Gtk2Hs has been demonstrated to work with it. Regards Jeremy ------------------------------------------------------------------------------ Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf _______________________________________________ wxhaskell-users mailing list wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
