On Wed, 20 Jan 2010 18:35:08 +0000
>>>>>> "Jeremy" == <jeremy.odonoghue-Re5JQEeQqe8AvxtiuMwx3w@...> wrote:
Jeremy> > I'm not sure where you found this quote. A (small) team of
Jeremy> > developers took on maintenance of wxHaskell over three years
Jeremy> ago, and we have been keeping it up to date ever since.
Well, wiki page (http://haskell.org/haskellwiki/WxHaskell) under
Status section says: "Since the core interface is generated
automatically from the wxEiffel binding..." with the link to wxEiffel
project and there is Project Status/Warning (25 July 2003) link
leading to: http://elj.sourceforge.net/status/
and, believe me, it looks quite depressive for potential wxhaskell user.
Jeremy> While there are some vestiges of the Eiffel heritage in the
Jeremy> wxHaskell source code, there is no dependency on the wxEiffel
Jeremy> binding. The dependency on wxEiffel really disappeared before I
Jeremy> became involved in the project.
Please, for the sake of wxhaskell, remove/explain/resolve this issue.
Jeremy> The latest wxHaskell release supports wxWidgets 2.8.10 (which I
Jeremy> believe is the most recent stable version), and we will update
Jeremy> to wxWidgets 3.0 shortly after this becomes available.
This sounds great!!
Jeremy> > Another concern is question of memory management touched upon
Jeremy> > in the following article:
Jeremy> > http://haskell.org/gtk2hs/archives/2005/07/15/automatic-memory-management/
What about this issue?
Jeremy> I suspect in practice that the learning curves are pretty
Jeremy> similar. I haven't done enough gtk2hs programming to be
Jeremy> certain, but the samples look really pretty similar, and the
Jeremy> programing style is a bit more imperative than many Haskell
Jeremy> programmers really like in both cases. This is somewhat
Jeremy> unavoidable given that the underlying toolkits are stateful
Jeremy> object-oriented in design.
This is nice to hear that wx(haskell) is not much harder that gtk(2hs).
As far as imperative style is concerned, it seems that FRP is not
ready yet, so noting to complain about here.
Jeremy> I originally became involved with wxHaskell after doing some
Jeremy> GTK GUIs (in Ocaml) for Windows at home, and being disappointed
Jeremy> with the results (and licensing issues - see below) - in fact,
Jeremy> this is how I first came to look at Haskell...
I'm too long involved with Haskell without learning it, but I'm not
giving it up and this time really determined to seriously jump
in. (I'm reading RWH atm.)
Jeremy> Mac is another story.
I'm more interested to get good support for Mac than on Windows.
Jeremy> AFAIK, the native GTK for Mac is still considered to be pretty
Jeremy> unstable, and the default theme, while functional, looks
Jeremy> like... GTK on Linux.
Yeah, I've found out that Imendio is not in business and GTK port is
Jeremy> wxWidgets (and wxHaskell) works very well on Mac - we have
Jeremy> support for creating application bundles, and UIs look
Jeremy> completely native. The same is true for Windows (I work about
Jeremy> 90% on Windows with wxHaskell)
How much (in %) of wxwidgets is bound in wxhaskell?
Jeremy> wxHaskell works fine on Linux, but since it depends on GTK to
Jeremy> render widgets, you'll have better performance and a smaller
Jeremy> app footprint if you just use gtk2hs, to be honest.
This is not critical for my app. The main number crunching will be,
anyway, done with Haskell bindings for some C-lib.
Jeremy> I guess the scorecard is therefore:
Jeremy> - Ease of use - wxhaskell and gtk2hs about equal
Jeremy> - Linux development - both work well, but gtk2hs scores
Jeremy> slightly for performance and app footprint
Jeremy> - Mac development - I definitely prefer wxHaskell. Native
Jeremy> look is *vital* for acceptability on Mac
Jeremy> - Windows development - both work well, but wxhaskell scores
Jeremy> for performance and app footprint
Jeremy> This means you will really need to weigh up the importance of
Here the weight goes to wxhaskell. It seems that's easier to learn
wx(widgets)haskell and have decent native look & feel instead of
fiddling with some platform-related issues by using some other
Jeremy> You don't mention documentation. I think the truth here is that
Jeremy> neither gtk2hs nor wxHaskell is as well documented as it should
Well, I must say that, although it is improving, it is something one
has to learn when having encounter with libs in Haskell. :-/
Jeremy> There are certainly bugs and strange behaviour in wxHaskell
Jeremy> that are not really documented well. I'm trying to change this
Jeremy> (in particular, the lack of 'intermediate level' on wxHaskell
Jeremy> information) in a new blog: http://wewantarock.wordpress.com
I saw it - it looks intriguing to create custom controls in Haskell,
but it is still way above my head.
Jeremy> We have put a lot of effort into making wxHaskell
Jeremy> installation 'just work' on all platforms using Cabal
Jeremy> recently. You can generally cabal install wx on any
Jeremy> platform with a working (recent) wxWidgets
Jeremy> installation and it works perfectly.
What is the plan for 6.12.1 support?
Jeremy> If I was writing a cross-platform app in C++, money no object,
Jeremy> I would probably choose Qt. Honestly, it's the best documented,
Jeremy> best designed and most complete of the toolkits. It does
Jeremy> require an (expensive) developer license for commercial
Jeremy> applications, which limits the appeal.
Heh, somehow I do not like Qt and although the licensing had changed,
I prefer to use community-driven toolkit instead of depending on some
corporation's mercy. Just see the situation with Maemo...
Jeremy> For me, wxWidgets is a good alternative because it provides a
Jeremy> 'native' UI experience on all platforms, is pretty robust and
Jeremy> complete, well documented and liberally licensed (commercial
Jeremy> applications explicitly permitted by the license). The
Jeremy> programming style is not as nice as Qt, but is, for me,
Jeremy> slightly preferable to GTK (my personal opinion is that the API
Jeremy> design is jut a little more consistent.
Is wx-3.0 part of wxTNG or the latter is quite different concept not
coming into existance soon?
Jeremy> The final killer with GTK for me is that I use (try to
Jeremy> evangelize) Haskell at work for certain tasks. My employer has
Jeremy> an absolute ban on the use of LGPL licensed code in any
Jeremy> internal project. This is not negotiable (before anyone tells
Jeremy> me that LGPL does allow commercial development, I'll only say
Jeremy> that I know that this is the opinion of some in the legal
Jeremy> profession, and certainly of many (most) developers, but not of
Jeremy> the lawyers who advise my employer, and they are not going to
Jeremy> change their minds on this). Therefore, in practice, gtk2hs is
Jeremy> not an option for me anyway.
Although I plan to release my app as open-source, it may happen that
my 'superior' may want to have some plugin as close-source, and then
the above info will be very helpful. Thanks a lot.
Jeremy> I am not sure how much I have helped you to move forward. The
Jeremy> truth is that either library would let you do the job, neither
Jeremy> is quite as well supported as it really ought to be, and the
Jeremy> reasons for and against each are rather finely balanced.
Your post is providing excellent info and gives me much more
confidence in wxhaskell. I really appreciate it.
May I just ask, if it is relevant for you, do you use some GUI
I'm thinking about DialogBlocks (looks as better option for wxhaskell
considering one needs only XRC support) vs. free wxFormBuilder,
i.e. is DialogBlock justifies to be supported over free tool to be
used for wxhaskell?
Jeremy> I wish you luck in your decision, and will try to support you
Jeremy> if you choose wxHaskell
I was looking (and helped a bit with their site) for quite some time
at gtk2hs project (Duncan persuaded me) :-) ,but since my teacher
recently moved to Mac OS, I'v e started to think that wxhaskell may be
In any case, I'll still think a bit - by the end of the month we're
going to vacation during February, and then by the March we'll know
for certain...although, based on all the info you've provided about
wxhaskell, I do not see any advantage in using gtk2hs (except that
memory issue which I mentioned above).
If I decide to go with wxhaskell, I'll definitely try to help the
project with all the skills I have.
Gour | Hlapicina, Croatia | GPG key: F96FF5F6