From: Daniel C. <dan...@th...> - 2009-04-30 12:01:30
|
Hello, I am not actually a wxHaskell user. I'm not even planning to make a GUI app soon. I am just a curious person and I was hoping I could ask a few questions: 1) First, a broad question: Why do you like wxHaskell? 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? The last couple of days I have been trying to learn about cross-platform GUIs with Haskell. In general I like Gtk+, WX and Qt, I think they are all great. But it looks like qtHaskell is too new, and Gtk doesn't support Mac well at all. But on the other hand, a lot of Haskell people seem to like Gtk2Hs. Is there anyone here that can compare wxHaskell with Gtk2Hs and/or qtHaskell? Daniel. |
From: Jeremy O'D. <jer...@gm...> - 2009-04-30 14:52:03
|
Hi Daniel, 2009/4/30 Daniel Carrera <dan...@th...>: > > 1) First, a broad question: Why do you like wxHaskell? Well, the wxHaskell list may not be the place to get objective advice, but... The main reason I got started with wxHaskell was that I needed to put together a GUI application for Windows, and I wanted to use Haskell to do it. At the time (it's much better now) Gtk+ was a pig to get working on Windows, and didn't have anything like a native look and feel. Mac was also 'nice to have' for me, and again, Gtk+ at the time worked only on the Mac X server. 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. 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. > 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? To get a *really* native OS X look and feel, you will need to do a few platform specific pieces of code, but it looks pretty good out of the box with just a recompile. It's not perfect (no cross-platform toolkit really can be), and there are a few more bugs on Mac than other platforms, but it is closer (out of the box) to OS X native look and feel than either of Gtk+ or Qt IMHO. Having said that, I think you can achieve excellent results with all of the toolkits, and if you want to go further, you'd better use HOC, which allows access to OS X native tools such as InterfaceBuilder - although the project does not appear to be very active these days. > The last couple of days I have been trying to learn about cross-platform > GUIs with Haskell. In general I like Gtk+, WX and Qt, I think they are > all great. But it looks like qtHaskell is too new, and Gtk doesn't > support Mac well at all. But on the other hand, a lot of Haskell people > seem to like Gtk2Hs. I've never used or seriously looked at QtHaskell, so I'm not very qualified to judge. The only comment I would make (after 15 minutes browsing the documentation) is that it looks as though the bindings are a fairly low level wrapper around the Qt libraries just now. I would expect the library itself to be pretty stable, as once you get the wrapper generating code correct, most things just work. There's little to choose, technically, between Gtk2Hs and wxHaskell, I think, and any choice you make is more likely to be about the platforms you care about most than about functionality or stability. For me, platform importance is Windows, Mac, Linux (in descending priority) and I think wxHaskell is a slightly better fit to my needs. I suspect that many in the community use mainly or only Linux, in which case Gtk2Hs is probably a better fit. Pragmatically, both Gtk2Hs and wxHaskell have pretty much everything most people would need, and more besides. There are probably more active developers of Gtk2Hs, but both projects are actively and enthusiastically maintained. Both also offer some higher level syntactic sugar over the bindings to make programming a bit easier, although in both cases it all feels a bit 'imperative' - you do all of the GUI stuff inside a 'do', and the code is pretty reminiscent of what you'd write in C++. Hope this helps, and more importantly, I hope you decide to write a GUI application in Haskell. Regards Jeremy O'Donoghue |
From: Daniel C. <dan...@th...> - 2009-04-30 16:00:42
|
Hi Jeremy, Thanks for the reply. Very good information. Jeremy O'Donoghue wrote: > 2009/4/30 Daniel Carrera <dan...@th...>: >> 1) First, a broad question: Why do you like wxHaskell? > > Well, the wxHaskell list may not be the place to get objective advice, but... For GUI toolkits, I think you can get advice that is either objective or useful, but not both. I prefer subjective-but-useful. > 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. > 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... >> 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? > > To get a *really* native OS X look and feel, you will need to do a few > platform specific pieces of code, but it looks pretty good out of the > box with just a recompile. I see. Thanks. > 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. The only real problem I see with Qt is that the qtHaskell bindings are very new. It looks like a one-man project. Even if it works, one still has to think about community support and documentation. > I've never used or seriously looked at QtHaskell, so I'm not very > qualified to judge. The only comment I would make (after 15 minutes > browsing the documentation) is that it looks as though the bindings > are a fairly low level wrapper around the Qt libraries just now. I > would expect the library itself to be pretty stable, as once you get > the wrapper generating code correct, most things just work. Ok. That's good to know. I thought QtHaskell might be unstable. In any case, if I ever write a GUI app with Haskell (knock on wood) I would write at a small program with each GUI before choosing one. > There's little to choose, technically, between Gtk2Hs and wxHaskell, I > think, and any choice you make is more likely to be about the > platforms you care about most than about functionality or stability. Good to know. In the context of my job, Windows and Linux are the most important, and Mac would be nice. Currently we use web applications because that is automatically cross-platform and trivially deployed. But some users have said that they aren't always on-line, so I thought it might be nice to make a desktop alternative some day. I've also been looking for an excuse to use Haskell for something. > Pragmatically, both Gtk2Hs and wxHaskell have pretty much everything > most people would need, and more besides. There are probably more > active developers of Gtk2Hs, but both projects are actively and > enthusiastically maintained. Both also offer some higher level > syntactic sugar over the bindings to make programming a bit easier, > although in both cases it all feels a bit 'imperative' - you do all of > the GUI stuff inside a 'do', and the code is pretty reminiscent of > what you'd write in C++. > > Hope this helps, and more importantly, I hope you decide to write a > GUI application in Haskell. Thanks for the help. Very good information. Cheers, Daniel. |
From: Jeremy O'D. <jer...@gm...> - 2009-04-30 16:22:20
|
Hi Daniel, 2009/4/30 Daniel Carrera <dan...@th...>: > Jeremy O'Donoghue wrote: >> 2009/4/30 Daniel Carrera <dan...@th...>: >>> 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 |
From: Daniel C. <dan...@th...> - 2009-04-30 20:27:58
|
Oh, can one use wxGlade with wxHaskell? I'm thinking of the XRC files (XML description of the UI). Personally I'm a big fan of using XML to describe GUIs. Come to think of it, a lot of toolkits seem to be going in that direction. Mozilla has XUL, Gtk has Glade, QtDesigner makes XML files, and wxWidgets has wxGlade which can make XRC files. Cheers, Daniel. |
From: Jeremy O'D. <jer...@gm...> - 2009-05-01 08:23:22
|
2009/4/30 Daniel Carrera <dan...@th...>: > Oh, can one use wxGlade with wxHaskell? I'm thinking of the XRC files (XML > description of the UI). Personally I'm a big fan of using XML to describe > GUIs. You can use XRC files with wxHaskell, although I should note that they are not currently type-safe (so you will get a crash if you load a resource and treat it as the wrong type of object (e.g. load a button into a list box). Someone (Mads, I think) showed a proof of concept for type safety on XRC, but I haven't had the time to implement it fully so far. I use something called wxFormBuilder on Windows to create my XRC files, which seems a little more complete than wxGlade, although both will do the job. There's a sample provided with wxHaskell which shows how to use XRC files, should you decide to go this way. Jeremy |
From: Mads L. <mad...@ya...> - 2009-05-01 13:01:47
|
Hi Jeremy O'Donoghue wrote: > Someone (Mads, I think) showed a proof of concept for type safety on > XRC, but I haven't had the time to implement it fully so far. Yes, that was me. See http://article.gmane.org/gmane.comp.lang.haskell.wxhaskell.devel/364/match=xrc I do not think it would take a long time, to make this usable for 90-95% of the widgets in a XRC file. However, personally I have no desire to use Glade or XRC files. But I know others do - to each his own. I do not want to develop this any further, for an imaginary user who may or may not exists. However, if somebody wants to this further developed and is willing to be ginnypig I could do so. But it is only second best. The best would be for somebody with a GUI app using XRC file, to implement type-safe XRC accessors themselves. Greetings, Mads |
From: Daniel C. <dan...@th...> - 2009-05-01 14:03:06
|
Mads Lindstrøm wrote: > However, personally I have no desire to use Glade or XRC files. But I > know others do - to each his own. Personally I have no opinion on Glade as I've never used it. When I say I like the idea of specifying a GUI with XML, the picture in my mind is something like XUL or HTML (hey, I'm a web developer). But these are much simpler than Glade XML. AFAIK you are not supposed to write Glade XML by hand. Daniel. |
From: Daniel C. <dan...@th...> - 2009-04-30 19:31:34
|
Jeremy O'Donoghue wrote: > 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). Btw, can you compile and deploy a wxHaskell program using only FOSS? For example, can you use mingw an still get the one DLL? Is it hard to get the one DLL? > 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. In all honesty, I'm not willing to put the effort in being 100% native, and I don't think my users would care either. Oh, I just thought of a new question: WebKit. I know that there is a project to port WebKit to wxWidgets. Can wxHaskell use wxWebKit? That would be uber-cool? (I don't know if I can use it for anything, but I can say it would be cool). Daniel. |
From: Jeremy O'D. <jer...@gm...> - 2009-05-01 08:37:13
|
2009/4/30 Daniel Carrera <dan...@th...>: > > Btw, can you compile and deploy a wxHaskell program using only FOSS? For > example, can you use mingw an still get the one DLL? Is it hard to get > the one DLL? I've never tried - I use Visual Studio to build wxWidgets and wxC - but it should work, as more users seem to use FOSS build chains than Microsoft, and all of the Unix platforms use exclusively FOSS tools to build. The wxWidgets build system is very configurable, and most build options seem to exist on all supported platforms. In general, I've found that if wxWidgets team claim something works, it works well (i.e. they do their QA!) There are people who use mingw to build the wxC component of wxHaskell. The single DLL aspect may require some minor fiddling with the wxC makefiles, but I suspect it should work once you've found the correct set of options. > Oh, I just thought of a new question: WebKit. I know that there is a > project to port WebKit to wxWidgets. Can wxHaskell use wxWebKit? That > would be uber-cool? (I don't know if I can use it for anything, but I > can say it would be cool). In principle, once it is in wxWidgets, it's pretty easy (trivial for a reasonably experienced C++ programmer) to wrap any new components - that's to say, once you have built wxWebKit, making it accessible from wxHaskell is easy (if tedious - for large/complex APIs). A quick glance at the wxWebKit website shows that there are a very large number of dependencies for building the component, so it might be tricky to incorporate into the standard wxHaskell distribution (I suspect many people would be put off by having to compile 9 significant Open Source libraries to get wxWidgets to build). Jeremy |