On Wed, 20 Jan 2010 18:35:08 +0000 >>>>>> "Jeremy" == <jeremy.odonoghue-re5jqeeqqe8avxtiumw...@public.gmane.org> >>>>>> wrote:
Hiya Jeremy, 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> > 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 not complete. 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> 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 :-D 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 Jeremy> portability. 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 toolkit. 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 Jeremy> be. 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 designer tool? 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 better option. 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. Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: F96FF5F6 ----------------------------------------------------------------
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ 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
