Which is better for developing GUI applications with Haskell, wxWidgets (via wxHaskell) or GTK (via Gtk2HS)?
What are the pros and cons of each? Does it vary depending on which platform you are targeting (I would primarily be working on OS X but would like my programs to work on Linux and Windows too)?
[Disclaimer: I am a wxHaskell maintainer]
Both are stable and fairly complete GUI bindings, and you could choose either for most projects with confidence. Both have some degree of 'higher-level' Haskell bindings, but in both cases you will need to drop into rather imperative 'C' style coding to get things done. My impression is that wxHaskell allows you to spend a little more time in the higher-level bindings, but I've not done much GTK2HS, and in any event, you definitely find yourself working on the thin end of the wrapper for both libraries - and I think the overall programming 'complexity' is similar in both cases.
Therefore, let's take the basic functionality as a given and concentrate on the differences. Please note that I genuinely believe that GTK2HS is an excellent piece of work, and that you will be happy if you choose it. Most of what I say below is a personal take on the differences, and why I choose to work on and with wxHaskell myself.
GTK2HS has a larger team working on it, and is released more regularly. wxHaskell is not updated as frequently, but the core team is active, and there are regular bugfixes, but with major new functionality being added rather more slowly than we would like (we all have day jobs).
wxHaskell gives true native application appearance on all supported platforms out of the box. GTK2HS is, of course, native on Linux and has a pretty good native theme on Windows (i.e. good enough to satisfy all but pedants...), but has GTK look and feel on OSX, and depends on having X11 installed. I believe that an OSX 'native' GTK library is under development, but is considered relatively immature. Once this is stable, GTK2HS should be able to easily benefit from the same 'partially native' look and feel (e.g. GTK OSX screenshot).
wxHaskell is probably a little easier to build if you are not on Linux (GTK2HS is likely easier if you are Linux hosted), but both are pretty complex to build, to be honest, as there are a significant number of dependencies in both cases.
It is slightly easier (IMHO) to distribute applications based on wxHaskell, simply because it has fewer library dependencies. I distribute applications using mainly InnoSetup on Windows, and as App bundles on OSX. I would admit that with only a small amount of extra work, the same could be done with GTK2HS, so this is probably the weakest argument in favour of wxHaskell.
It is my personal opinion that wxHaskell is friendlier to closed source (e.g. commercial) developments. This is, of course, the subject of interminable flame wars, so I will only say that wxHaskell is under the wxWidgets license which unambiguously allows for closed source development. GTK2HS is LGPL, so you'll need to ask your lawyer - although I must make it clear that many people and companies have concluded that LGPL is compatible with commercial development; the lawyers at the company I work for have concluded that it is inappropriate for our projects.
I think that if Linux was my main development and delivery platform, I'd probably use GTK2HS. It isn't, however: I deliver mainly to Windows with occasional OSX, and I think wxHaskell is a better match to these platforms, although both options support all three platforms.
I hope this will help you with your choice.
A consideration is that currently it is slightly easier to get wxHaskell to work natively on Mac OS X. GTK2HS depends on GTK, which does have an implementation using native widgets on Mac OS X, but that implementation is not as easily built as the wxWidgets implementation for Mac OS X is.
Therefore, if you want to develop code to run without X11.app, currently you are slightly better off with wxHaskell.
Note however that this is quickly changing:
http://www.haskell.org/haskellwiki/Gtk2Hs#Using_the_GTK.2B_OS_X_Framework
shows how to use GTK2HS with native GTK+ on Mac OS X.
One advantage of GTK2HS is its GLADE support, making the development of simple UI very quick. The higher level combinators in wxHaskell mitigate most of that advantage, but they do require a deeper understanding of how you want your interface to look and behave, and therefore are harder to use in an exploratory fashion.
I have pretty incomplete information, but since you have no answers yet, maybe incomplete information is better than none.
The question to ask is this: is the toolkit just a wrapper around C-like functionality, or is there an additional layer that gives the toolkit a more "native Haskell-like" API? When wxHaskell was first announced at the Haskell workshop, the development of the native Haskell API looked extremely promising, but was still incomplete. It looks as if the "Haskellized" API for wxHaskell is still being worked on, whereas the Gtk2Hs project doesn't mention this issue at all. For that reason I'd recommend wxHaskell.
Personally I would look into some sort of Reactive package/extension. It seems to sit with the paradigm much much closer. Instead of specifying your graphical stuff imperatively, you can do it declaratively. Example (not representative of any particular language or implementation):
x, y, z :: Int
click, buttonclicked :: Bool
x = <X coordinate of mouse>
y = <Y coordinate of mouse>
click = <Whether mouse button is currently being pressed>
z = x + y
buttonclicked = (x == 10 && y == 10 && click)
Buttonclicked and z will be automatically updated every time x and y change.
You could then have some logic somewhere that looks something like this:
if buttonclicked then <do something> else <do something else>
This is all very fuzzy though. Just look into some real reactive interfaces
Related
I'd like to develop a desktop app with Ruby. However, I'd like to have a native GUI on every platform (as opposed to a cross-platform GUI Toolkit that looks consistently awful across all platforms).
I expect to have to do different GUIs for each platform (as it's not just looks but also behaviors and idioms that are different), but I wonder what my options are? Especially wondering if there is a clean way to separate front and backend and bind the data properly?
Target Platforms are Windows (Vista & 7, XP is a Bonus), Mac OS X (Cocoa) and Linux (GTK? Qt? No idea).
The Ruby language has excellent Qt library bindings and your scripts will be cross-platform.
Two Kinds of Cross-Platform
It turns out there are two kinds of cross-platform UI toolkits.
One kind draws its own controls, and, like you said, looks equally bad on all platforms. Even worse: it looks out-of-place on all except one.
But there is another kind that just provides a harmonized interface to the native widgets. The best of example of this kind of toolkit is SWT1.. It looks, it is, approximately fully native on each platform, yet it has but a single API.
So you shouldn't simply rule-out all cross-platform toolkits, just rule out the ones that fake the native UI.
Develop the Wrapper Interface
There is a second way. If your program's interface with the user can be directed through a relatively narrow interface, you can simply develop to that interface and then implement the bottom part of it for each platform you want to support. Yes, you have to rewrite one module, but all the other modules stay exactly the same and you get native widgets. You also get the smallest possible executable without lots of bloat.
Perhaps most importantly, you don't have a complex and opaque software layer between your code and the native windowing system. You will probably save as much time debugging as you spend writing the extra module for your first port.
1. I know my Java examples won't help you much unless you are using jRuby, but SWT vs Swing is a really pure example of the right-vs-wrong (IMHO) UI toolkit divide.
The WxWidgets interface claims to use the native interface on Windows, OS X, Linux and UNIX through one API.
Coworkers who have used it in the past enjoyed it well enough, but I've not used it myself.
After a long evaluation period of mainstream toolkits Qt, WxWidget, GTK i came to the conclusion that it does not make sense to religiously equalize the different platform. Now more then ever before.
In the days before Java portability meant, that platform dependent code was located in known places and should be small but not none. No write once, run everywhere marketing.
Is there any GUI tookit - experimental or commerical (even outdated or dead projects) - that is going this way. It would need to give me native widgets of course. I would like to have a look at them before i start my own toolkit
If you think this is a stupid idea tell me why (cause everybody else is doing it differently there may be a reason i don't see)
As someone who zealously believes that GUIs should be drawn with native widgets, I must say I've been very impressed with wxWidgets, although you mention that at the beginning.
As far as I know, wxWidgets uses native widgets whenever possible, and indeed it does also include platform-specific features that are neither possible nor relevant on other platforms. A good example of this is how you can use the native Mac OS X menu, while on other systems it won't do squat. There are other and better examples.
I must mention wxPython in particular, in case you either don't want to or just don't have the time to write a C++ program. wxPython astonished me when I tried it out first, and I even managed to make a stand-alone .exe file from it that worked on a fresh install of Windows 2000 without any updates or particular runtime environments.
If wxWidgets doesn't suit your needs, I wonder what would. :) Hurray for wxWidgets!
AFAIK, wxWidgets uses the platform's native widgets whenever possible.
Have a look at SWT, it tries to use the widgets of the underlying platform as much as possible.
Is there, by chance, an emerging Haskell UI framework for Windows?
I recently took up looking over the language, and from what I see, it would be for great little "one-off" applications (elaborate scripts).
However, without a good UI framework I can't see it getting in under the smoke and mirrors of the more obvious contenders.
I've read that there are many frameworks, but none are full-featured.
I'm just wondering if this is something that's on the rise, or is it simply too difficult to get enough developers going in the same direction with one?
The two main frameworks are wxHaskell and Gtk2Hs. Both of these have been used for real work. From what I know my preference would be Gtk2Hs because it handles resources properly (i.e. uses the GC). wxHaskell requires the programmer to release widgets once they are no longer required, so you can get all the classic memory leaks and stale pointer screws with it.
The problem with both is that everything is in the IO monad. This reflects the fact that they are comparatively thin wrappers around existing GUI libraries for imperative languages. Of course this means you are no worse off than you would be writing a GUI in an imperative language, but you are hardly much better off either.
There are some interesting experimental libraries to be found on Hackage, including Grapefruit and Conal Elliott's "Tangible Values" ideas in GuiTV. Both of these try for a more declarative approach.
(Disclaimer: I am the wxHaskell maintainer)
Both wxHaskell and Gtk2Hs are more or less complete. That's to say, both wrap a great deal of the functionality provided by their underlying libraries. They also both, as mentioned earlier, require a rather 'imperative' style of programming in the IO monad.
There have been many discussions on the relative merits of each. I would say that wxHaskell is the easier of the two to get working, especially on Windows, as it can be installed via cabal (see http://www.haskell.org/haskellwiki/WxHaskell/Install#On_Windows)
The FRP frameworks (Grapefruit and others) provide a more 'functional' style of programming, at the cost of having much reduced widget coverage. I have the feeling that this is still an open research area, and not really ready for 'prime time'.
In practice, I've never had resource management issues with wxHaskell, although I agree that it's possible, and is an area handled better by Gtk2Hs, which uses reference counting in the underlying library.
For completeness, I should also mention that a Qt binding (QtHaskell?) also exists - it is relatively young, but apparently reasonably complete.
I rather feel that the Haskell community, small as it is, would do well to fix on one GUI framework, but accept the difficulty of this (e.g. licensing, support for all OS platforms etc.).
Also you can use wxWidgets (i mean C++ library) with Haskell. Here is an example: https://bitbucket.org/afiskon/hs-a-star-gui/src Such approach has some advantages over wxHaskell: 1. You can use UI generators (Code::Blocks, wxFormBuilder) 2. Your application takes less disk space 3. You can use all features of wxWidgets.
It should also be noted, that last version of wxHaskell uses wxWidgets 2.9, which probably will never be ported to Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=16;bug=613431
Every time I see a discussion on software development, always someone suggests or exalts the qualities of Smalltalk, be it the beautiful language constructs or the better implementation of basically everything.
So I was curious, is anybody developing in Smalltalk? can Smalltalk actually be used to develop software on the Mac? Or what is the target platform for Smalltalk? What is the poster child for this apparently fantastic but unpopular language?
Smalltalk isn't really used for GUI application development on the Mac in any major way. The only distribution that could produce native apps was Ambrai Smalltalk, and that died in beta AFAIK. Squeak is the most popular Smalltalk variant nowadays, but you will be torn limb from limb if you release a Mac OS X app that looks like Squeak. It's worth checking out if you're interested in learning the language (which is still unique in a lot of ways), but you're probably not going to be developing OS X apps with it.
If you would like something similar, check out MacRuby. Ruby is as close as you can get to Smalltalk without actually being Smalltalk — total object orientation, dynamic, 100% message-based, heavy use of blocks, etc. MacRuby is an implementation being developed by Apple specifically for making OS X applications.
Mac OS X's native Objective-C is also heavily Smalltalk-inspired (it's basically a big chunk of Smalltalk's object system and syntax bolted onto C), but owing to its extreme C compatibility, it falls a little further from the tree.
Take a look at fscript, which is essentially a smalltalk-like language for Objective C.
Luis: do you want to do desktop application for Mac ? or you want to program in Mac? If you want to do a web application for example, you can perfectly use Squeak or Pharo. If you want to do native mac applications, you should see the Mars project for Squeak:
http://smallworks.com.ar/productos/Mars
As an example, most of the Pharo users and developers are under Mac.
http://www.pharo-project.org/home
download and try it at least for a couple of hours!
I still believe that Squeak is well worth investigating, if only to broaden your mind a little. As for the poster child for Smalltalk, it's probably Seaside.
Squeak isn't its UI. You can configure Morphic heavily (look at how similar Pharo's is to OSX, for instance). Or you can just use native widgets with wxSqueak.
This deserves some attention:
"Objective-Smalltalk was created specifically to solve practical problems that have been encountered in 25 years of Objective-C and Smalltalk use, but with a theoretical framework that solves many of these problems elegantly and minimally, rather than by bolting on special feature after special feature."
http://objective.st/
I want to start programming with D. I have a simple application in mind that needs a GUI but I want to make sure it's portable to Linux/Windows/Mac equally well and with minimal (no) change for each platform.
wxD is looking like the contender of choice because I know the wx toolkit already.
I see fltk4d as a contender and a (unfinished) wrapper around Qt.
Are there any other truly cross platform GUI toolkits for D that will go where I want with little effort and what would the the toolkit of choice for people here?
GtkD should be a very good option for you as a stable Windows/Linux/Mac GUI toolkit.
DWT was once considered the standard, it has its own newsgroup on the Digital Mars server and I think Walter Bright may have called it the standard too. I don't think it's completely working on Mac but this should change in the future.
Here is a nice list of some other options but most have less active development and/or are not yet ready for production.
I have not used any of D's GUI libraries, but I would go with wxD if I wanted to use one now. I would pick it because I think wxD would have the most native looking controls and is cross-platform. Especially since you already know wx, it looks like a good choice.
I'm actually writing a cross-platform GUI library, Dynamin, but I have not released it yet. It is not a port; ported libraries tend to not have as nice of APIs or take advantage of as many language features. But it is not far enough along to do more than simple programs. I also don't have a Mac backend or GTK theme yet.