Hi Gour,
2010/1/19 Gour <g...@gour-nitai.com>
> Now, based on what I know so far wxhaskell may be better supported on
> Mac since GTK+ port is not finished. otoh, I'm a bit concerned about
> "Since the core interface is generated automatically from the wxEiffel
> binding..." and visiting the project show the status notice:
>
> "The 0.7 release will probably be the last official release.
>
> The project lost its core developer following the 0.7 release in late
> June 2003 and it is unlikely that anyone will be able to take on this
> vital role. "
>
So, my question is if this dependency on wxEiffel will change soon,
> especially considering the upcoming wx-3.0 release?
>
> I'm not sure where you found this quote. A (small) team of developers took
on maintenance of wxHaskell over three years ago, and we have been keeping
it up to date ever since.
While there are some vestiges of the Eiffel heritage in the wxHaskell source
code, there is no dependency on the wxEiffel binding. The dependency on
wxEiffel really disappeared before I became involved in the project.
The latest wxHaskell release supports wxWidgets 2.8.10 (which I believe is
the most recent stable version), and we will update to wxWidgets 3.0 shortly
after this becomes available.
> Another concern is question of memory management touched upon in the
> following article:
>
> http://haskell.org/gtk2hs/archives/2005/07/15/automatic-memory-management/
>
>
> So, can someone share some thoughts about gtk2hs vs. wxhaskell with
> the reference to ease of use, learning curve etc. for a noob not being
> too familiar with none of the toolkits and considering suitability for
> multi-platform development in Haskell for (priority order) Linux, Mac
> and Windows?
>
I suspect in practice that the learning curves are pretty similar. I haven't
done enough gtk2hs programming to be certain, but the samples look really
pretty similar, and the programing style is a bit more imperative than many
Haskell programmers really like in both cases. This is somewhat unavoidable
given that the underlying toolkits are stateful object-oriented in design.
I originally became involved with wxHaskell after doing some GTK GUIs (in
Ocaml) for Windows at home, and being disappointed with the results (and
licensing issues - see below) - in fact, this is how I first came to look at
Haskell...
I understand that the GTK situation on Windows is much better now, and that
the GTK theme for Windows looks pretty close to native unless you look very
closely. Mac is another story. AFAIK, the native GTK for Mac is still
considered to be pretty unstable, and the default theme, while functional,
looks like... GTK on Linux.
wxWidgets (and wxHaskell) works very well on Mac - we have support for
creating application bundles, and UIs look completely native. The same is
true for Windows (I work about 90% on Windows with wxHaskell)
wxHaskell works fine on Linux, but since it depends on GTK to render
widgets, you'll have better performance and a smaller app footprint if you
just use gtk2hs, to be honest.
I guess the scorecard is therefore:
- Ease of use - wxhaskell and gtk2hs about equal
- Linux development - both work well, but gtk2hs scores slightly for
performance and app footprint
- Mac development - I definitely prefer wxHaskell. Native look is *vital*
for acceptability on Mac
- Windows development - both work well, but wxhaskell scores for
performance and app footprint
This means you will really need to weigh up the importance of portability.
You don't mention documentation. I think the truth here is that neither
gtk2hs nor wxHaskell is as well documented as it should be. There are
certainly bugs and strange behaviour in wxHaskell that are not really
documented well. I'm trying to change this (in particular, the lack of
'intermediate level' on wxHaskell information) in a new blog:
http://wewantarock.wordpress.com
I've noticed that wxhaskell is improving ease of install (I'm arch
> user) -
>
> http://archhaskell.wordpress.com/2010/01/18/wxhaskell-packaged-for-arch/
>
> We have put a lot of effort into making wxHaskell installation 'just work'
on all platforms using Cabal recently. You can generally cabal install wx on
any platform with a working (recent) wxWidgets installation and it works
perfectly.
> and it may be that more devs are actively working on it atm.
>
The number is small for both, I suspect. Almost everyone interested in
maintaining this stuff has a day job and very little time to spare.
> Otoh, wx toolkit is often not very much likened (upon mentioning it),
> at least, on Linux platform where people recommend Qt and GTK+ (in
> general, I prefer GTK+ look over Qt which I do not consider as
> option). Why is it so?
>
I think you need to look at the toolkits in respect of their origins - to
some extent, language bindings exist slightly outside of these issues.
On Linux, Qt was the choice of the KDE devs and GTK was developed as a part
of the Gnome project. Back in the day (more than 10 years ago) there were
huge flamewars about licensing, freedom and the merits of C++ over C. The
end result is that, at least on Linux, Qt is seen as 'KDE-centric' and GTK
is seen as Gnome-centric. People often express an (unreasoned) preference
depending on their preferred desktop.
wxWidgets was never used by a major Linux desktop, and is sometimes decried
as 'portable MFC' - there is some truth in this, as the project essentially
started out as a portable and liberally licensed implementation of something
very like MFC. In addition, since it relies on GTK (on Linux) for its widget
drawing, there is no compelling reason to use it, at least for a desktop
environment (which, by its very nature tends to be OS-specific).
While I personally think that it was a strange choice to write GTK in C
rather than C++ (the underlying gobject library is, to some extent, an
implementation of a small subset of C++ object oriented facilities without
the compiler support), the fact is that being based on C means that it is
*much* easier to write a language binding for GTK than for wxWidgets or Qt
(both of which are written in C++) since every language has a C binding and
almost none have C++ bindings.
If I was writing a cross-platform app in C++, money no object, I would
probably choose Qt. Honestly, it's the best documented, best designed and
most complete of the toolkits. It does require an (expensive) developer
license for commercial applications, which limits the appeal.
For me, wxWidgets is a good alternative because it provides a 'native' UI
experience on all platforms, is pretty robust and complete, well documented
and liberally licensed (commercial applications explicitly permitted by the
license). The programming style is not as nice as Qt, but is, for me,
slightly preferable to GTK (my personal opinion is that the API design is
jut a little more consistent.
The final killer with GTK for me is that I use (try to evangelize) Haskell
at work for certain tasks. My employer has an absolute ban on the use of
LGPL licensed code in any internal project. This is not negotiable (before
anyone tells me that LGPL does allow commercial development, I'll only say
that I know that this is the opinion of some in the legal profession, and
certainly of many (most) developers, but not of the lawyers who advise my
employer, and they are not going to change their minds on this). Therefore,
in practice, gtk2hs is not an option for me anyway.
I am not sure how much I have helped you to move forward. The truth is that
either library would let you do the job, neither is quite as well supported
as it really ought to be, and the reasons for and against each are rather
finely balanced.
I wish you luck in your decision, and will try to support you if you choose
wxHaskell
Best regards
Jeremy
------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
wxhaskell-users mailing list
wxhaskell-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
