From: Gour <go...@go...> - 2010-01-19 09:59:16
Attachments:
signature.asc
|
Hiya! Haskell noob considering to write desktop gui app by developing on Linux... Moreover, I'd like the application to be multi-platform and to be nicely supported on Mac OS X and finally (the least priority) on Windows. For long time I was considering gtk2hs (yeah, I'm 'learning' Haskell too long), but recently one of the important targets for the app switched from Windows to Mac, and now I'm considering wxhaskell as well... 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? 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've noticed that wxhaskell is improving ease of install (I'm arch user) - http://archhaskell.wordpress.com/2010/01/18/wxhaskell-packaged-for-arch/ and it may be that more devs are actively working on it atm. 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? Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: F96FF5F6 ---------------------------------------------------------------- |
From: Gour <go...@go...> - 2010-01-20 06:40:17
Attachments:
signature.asc
|
Hiya! Haskell noob considering to write desktop gui app by developing on Linux... Moreover, I'd like the application to be multi-platform and to be nicely supported on Mac OS X and finally (the least priority) on Windows. For long time I was considering gtk2hs (yeah, I'm 'learning' Haskell too long), but recently one of the important targets for the app switched from Windows to Mac, and now I'm considering wxhaskell as well... 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? 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've noticed that wxhaskell is improving ease of install (I'm arch user) - http://archhaskell.wordpress.com/2010/01/18/wxhaskell-packaged-for-arch/ and it may be that more devs are actively working on it atm. 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? Sincerely, Gour p.s. I've sent post directly to the list, but it was held for moderator's approval despite of being subscribed? -- Gour | Hlapicina, Croatia | GPG key: F96FF5F6 ---------------------------------------------------------------- |
From: Jeremy O'D. <jer...@gm...> - 2010-01-20 18:35:16
|
Hi Gour, 2010/1/19 Gour <go...@go...> > 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 |
From: Gour <go...@go...> - 2010-01-20 19:29:55
Attachments:
signature.asc
|
On Wed, 20 Jan 2010 18:35:08 +0000 >>>>>> "Jeremy" == <jer...@pu...> 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 ---------------------------------------------------------------- |
From: Jeremy O'D. <jer...@gm...> - 2010-01-21 14:23:33
|
Hi Gour, On 20 January 2010 19:30, Gour <go...@go...> wrote: > On Wed, 20 Jan 2010 18:35:08 +0000 > >>>>>> "Jeremy" == < > jer...@pu...> wrote: > Please, for the sake of wxhaskell, remove/explain/resolve this issue. > > I have just updated the wiki text here. Thanks for the information. > 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? > I need to look into this a bit further. The wxHaskell documentation (Graphics.UI.WXCore.WxcOjbect) says "Objects are not automatically deleted. Normally you can use a delete function like windowDelete to delete an object. However, almost all objects in the wxWindows library are automatically deleted by the library. The only objects that should be treated with acre are resources [such] as bitmaps, fonts and brushes" (the latter are reference counted objects in wxWidgets). I expect that this investigation will turn into a blog article, as it really involves tracing the lifecycle of a control. How much (in %) of wxwidgets is bound in wxhaskell? > Almost all of the core widgets are wrapped, although some of the more complex ones are not. Much of the non-essential and non-GUI related functionality does not get much attention because Haskell generally already has very satisfactory (and idiomatic) libraries for these.. > > 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? > > To be honest, it will probably happen (almost immediately) when Haskell Platform is released with 6.12.x - I really don't have the time to compile GHC and the minimum set of libraries myself. It may even work out of the box (at most with minimal library dependency changes). > Is wx-3.0 part of wxTNG or the latter is quite different concept not > coming into existance soon? > >From what I can see of wxWidgets 2.9.x, it's pretty evolutionary without radical changes. We already use the Unicode build of wxWidgets, and pervasive Unicode is one of the headline features for 2.9.x/3.0 > > 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? > > I believe any tools should generate the same XRC. I found wxFormBuilder to be fine, but DialogBlocks is probably a good alternative. One issue for me is that XRC really violates type-safety in wxHaskell. I think a better way forward in the long run will be to have a tool which generates code from XRC, rather than loading the resources using the resource subsystem. Regards Jeremy |
From: Gour <go...@go...> - 2010-01-21 17:52:03
Attachments:
signature.asc
|
On Thu, 21 Jan 2010 12:32:16 +0000 >>>>>> "Jeremy" == "Jeremy O'Donoghue" wrote: Jeremy> I have just updated the wiki text here. Thanks for the Jeremy> information. Thanks a lot. Now it's much more encouraging for someone considering to use wxhaskell. Jeremy> I need to look into this a bit further. OK. Jeremy> I expect that this investigation will turn into a blog article, Jeremy> as it really involves tracing the lifecycle of a control. That would be very good since the referenced article makes some strong statements as: "...wxHaskell in that sense is worse than any Java Swing/AWT application since even there you don’t have to worry about freeing objects." Jeremy> Almost all of the core widgets are wrapped, although some of Jeremy> the more complex ones are not. Much of the non-essential and Jeremy> non-GUI related functionality does not get much attention Jeremy> because Haskell generally already has very satisfactory (and Jeremy> idiomatic) libraries for these.. Nice to hear...Maybe it would be good to have some kind of 'status' page generated showing what is remaining to be bound and what is covered to help potential contributors to know where/how to help? Jeremy> To be honest, it will probably happen (almost immediately) Jeremy> when Haskell Platform is released with 6.12.x - I really Jeremy> don't have the time Jeremy> to compile GHC and the minimum Jeremy> set of libraries myself. It may even work out of the box Jeremy> (at most with minimal library dependency changes). Thank you. Now it's clear that wxhaskell is following HP. Jeremy> From what I can see of wxWidgets 2.9.x, it's pretty Jeremy> evolutionary without radical changes. We already use the Jeremy> Unicode build of wxWidgets, and pervasive Unicode is one Jeremy> of the headline features for 2.9.x/3.0 OK. I saw one thread in wx mailing list (http://tinyurl.com/yandrh3) from where I've concluded that VZ has on mind something more drastic than what 3.0 brings up. Jeremy> I believe any tools should generate the same XRC. I found Jeremy> wxFormBuilder to be fine, but DialogBlocks is probably a Jeremy> good alternative. Thanks for the tips. Jeremy> One issue for me is that XRC really violates type-safety in Jeremy> wxHaskell. Hmm...afaics, looking at gtk2hs glade-example, I've feeling that type-safety works there: ************* code-here********************* -- load up the glade file dialogXmlM <- xmlNew "simple.glade" let dialogXml = case dialogXmlM of (Just dialogXml) -> dialogXml Nothing -> error "can't find the glade file \"simple.glade\" \ \in the current directory" -- get a handle on a couple widgets from the glade file window <- xmlGetWidget dialogXml castToWindow "window1" button <- xmlGetWidget dialogXml castToButton "button1" [...] ************* code-here **************************************** Is it possible to achieve it with XRC? Jeremy> I think a better way forward in the long run will be Jeremy> to have a tool which generates code from XRC, rather than Jeremy> loading the resources using the resource subsystem. Huh, that would be terrific, but it should (probably) come from the wxhaskell team adding support to some GUI tool, do you agree? Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: F96FF5F6 ---------------------------------------------------------------- |
From: Conal E. <co...@co...> - 2010-01-23 01:15:33
|
Hi Gour, I've worked with both wxhaskell and gtk2hs. I prefer wxhaskell for elegant design. And I like that it gives me a native Mac OS X look. There is a partially working native Gtk for Mac, but I don't think it works with 3D, which was a requirement for me. The X11 mode is painful & ugly, and awfully disappointing considering how much more expensive a Mac is than a Linux machine. In spite of these reasons, I'm using gtk2hs for the time being, because wxhaskell has a problem that makes it very unfriendly to ghci. The second attempt to display a GUI kills its host process. This behavior is okay for many (but not all) compiled programs, but is a killer for interactive/exploratory development. As soon as I hear that this problem is fixed, I'll very happily return to wxhaskell. Longer term, I want Haskell GUI programming to move away from these massively complex OO imperative frameworks to something much more elegant and harmonious with the spirit and benefits of pure functional/denotative programming. Regards, - Conal On Tue, Jan 19, 2010 at 1:59 AM, Gour <go...@go...> wrote: > Hiya! > > Haskell noob considering to write desktop gui app by developing on > Linux... > > Moreover, I'd like the application to be multi-platform and to be > nicely supported on Mac OS X and finally (the least priority) on > Windows. > > For long time I was considering gtk2hs (yeah, I'm 'learning' Haskell > too long), but recently one of the important targets for the app > switched from Windows to Mac, and now I'm considering wxhaskell as > well... > > 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? > > 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've noticed that wxhaskell is improving ease of install (I'm arch > user) - > > http://archhaskell.wordpress.com/2010/01/18/wxhaskell-packaged-for-arch/ > > and it may be that more devs are actively working on it atm. > > 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? > > > Sincerely, > Gour > > -- > > Gour | Hlapicina, Croatia | GPG key: F96FF5F6 > ---------------------------------------------------------------- > |
From: Günther S. <gue...@we...> - 2010-01-23 03:24:34
|
Hi Conal, I recently switched my app from Haskell to Smalltalk because I was unable to code interdependent widgets with wxHaskell, ie. a bunch of dropdowns where changing the value of one needs to change the set of elements available in others. Well I was unable to code this in Haskell without using tons of either MVars or IORefs. If you know of a way or an example to do this in wxHaskell I'd certainly appreciate it if you'd share it with us. The plain business logic of the app was so simple to code in haskell it was a pleasure. But I could not code the GUI part in wxHaskell, I just wouldn't know how and neither in gtk2hs for that matter. I also had the impression that the higher level projects in the GUI or FRP department are all started and then gotten stuck and abandoned, it seems to be an unsolved issue, please correct me if I'm wrong. Günther Am 23.01.10 02:15, schrieb Conal Elliott: > Hi Gour, > > I've worked with both wxhaskell and gtk2hs. I prefer wxhaskell for > elegant design. And I like that it gives me a native Mac OS X look. > There is a partially working native Gtk for Mac, but I don't think it > works with 3D, which was a requirement for me. The X11 mode is painful > & ugly, and awfully disappointing considering how much more expensive a > Mac is than a Linux machine. > > In spite of these reasons, I'm using gtk2hs for the time being, because > wxhaskell has a problem that makes it very unfriendly to ghci. The > second attempt to display a GUI kills its host process. This behavior > is okay for many (but not all) compiled programs, but is a killer for > interactive/exploratory development. As soon as I hear that this > problem is fixed, I'll very happily return to wxhaskell. > > Longer term, I want Haskell GUI programming to move away from these > massively complex OO imperative frameworks to something much more > elegant and harmonious with the spirit and benefits of pure > functional/denotative programming. > > Regards, - Conal > > On Tue, Jan 19, 2010 at 1:59 AM, Gour > <go...@go... > <mailto:go...@go...>> wrote: > |
From: Conal E. <co...@co...> - 2010-01-23 19:13:49
|
2010/1/22 Günther Schmidt <gue...@we...> > Hi Conal, > > I recently switched my app from Haskell to Smalltalk because I was > unable to code interdependent widgets with wxHaskell, ie. a bunch of > dropdowns where changing the value of one needs to change the set of > elements available in others. > > Well I was unable to code this in Haskell without using tons of either > MVars or IORefs. > > If you know of a way or an example to do this in wxHaskell I'd certainly > appreciate it if you'd share it with us. > I haven't delved far into what can be done with wxHaskell. I've been more interested in exploring functional/denotative GUI programming. > The plain business logic of the app was so simple to code in haskell it > was a pleasure. But I could not code the GUI part in wxHaskell, I just > wouldn't know how and neither in gtk2hs for that matter. > > I also had the impression that the higher level projects in the GUI or > FRP department are all started and then gotten stuck and abandoned, it > seems to be an unsolved issue, please correct me if I'm wrong. > > Günther > Yes, I'd say unsolved as well. Work continues. I'm optimistic. - Conal Am 23.01.10 02:15, schrieb Conal Elliott: > > Hi Gour, > > > > I've worked with both wxhaskell and gtk2hs. I prefer wxhaskell for > > elegant design. And I like that it gives me a native Mac OS X look. > > There is a partially working native Gtk for Mac, but I don't think it > > works with 3D, which was a requirement for me. The X11 mode is painful > > & ugly, and awfully disappointing considering how much more expensive a > > Mac is than a Linux machine. > > > > In spite of these reasons, I'm using gtk2hs for the time being, because > > wxhaskell has a problem that makes it very unfriendly to ghci. The > > second attempt to display a GUI kills its host process. This behavior > > is okay for many (but not all) compiled programs, but is a killer for > > interactive/exploratory development. As soon as I hear that this > > problem is fixed, I'll very happily return to wxhaskell. > > > > Longer term, I want Haskell GUI programming to move away from these > > massively complex OO imperative frameworks to something much more > > elegant and harmonious with the spirit and benefits of pure > > functional/denotative programming. > > > > Regards, - Conal > > > > On Tue, Jan 19, 2010 at 1:59 AM, Gour > > <go...@go... > > <mailto:go...@go...>> wrote: > > > > > > > ------------------------------------------------------------------------------ > 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 > wxh...@li... > https://lists.sourceforge.net/lists/listinfo/wxhaskell-users > |
From: Gour <go...@go...> - 2010-01-23 07:23:11
Attachments:
signature.asc
|
On Fri, 22 Jan 2010 17:15:00 -0800 >>>>>> "Conal" == "Conal Elliott" wrote: Hello Conal, Conal> I've worked with both wxhaskell and gtk2hs. I prefer wxhaskell Conal> for elegant design. And I like that it gives me a native Mac OS Conal> X look. There is a partially working native Gtk for Mac, but I Conal> don't think it works with 3D, which was a requirement for me. This is nice to hear about wxhaskell. Conal> In spite of these reasons, I'm using gtk2hs for the time being, Conal> because wxhaskell has a problem that makes it very unfriendly to Conal> ghci. The second attempt to display a GUI kills its host Conal> process. This behavior is okay for many (but not all) compiled Conal> programs, but is a killer for interactive/exploratory Conal> development. As soon as I hear that this problem is fixed, I'll Conal> very happily return to wxhaskell. Isn't it that, at one point of time, gtk2hs has similar problem when working within ghci? Conal> Longer term, I want Haskell GUI programming to move away from Conal> these massively complex OO imperative frameworks to something Conal> much more elegant and harmonious with the spirit and benefits of Conal> pure functional/denotative programming. I must say that I'm looking/reading your FRP stuff from the distance thinking it's way above the head of this Haskell noob, but I tend to agree that it should be possible to do GUI in Haskell in a different way. Do you consider it can be achieved on the top of present libs like wx/gtk+ or it would require writing new stuff? Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: F96FF5F6 ---------------------------------------------------------------- |
From: Conal E. <co...@co...> - 2010-01-23 18:48:01
|
On Fri, Jan 22, 2010 at 11:23 PM, Gour <go...@go...> wrote: > On Fri, 22 Jan 2010 17:15:00 -0800 > >>>>>> "Conal" == "Conal Elliott" wrote: > > Hello Conal, > > Conal> I've worked with both wxhaskell and gtk2hs. I prefer wxhaskell > Conal> for elegant design. And I like that it gives me a native Mac OS > Conal> X look. There is a partially working native Gtk for Mac, but I > Conal> don't think it works with 3D, which was a requirement for me. > > This is nice to hear about wxhaskell. > > Conal> In spite of these reasons, I'm using gtk2hs for the time being, > Conal> because wxhaskell has a problem that makes it very unfriendly to > Conal> ghci. The second attempt to display a GUI kills its host > Conal> process. This behavior is okay for many (but not all) compiled > Conal> programs, but is a killer for interactive/exploratory > Conal> development. As soon as I hear that this problem is fixed, I'll > Conal> very happily return to wxhaskell. > > Isn't it that, at one point of time, gtk2hs has similar problem when > working within ghci? > I don't know gtk2hs's history. > Conal> Longer term, I want Haskell GUI programming to move away from > Conal> these massively complex OO imperative frameworks to something > Conal> much more elegant and harmonious with the spirit and benefits of > Conal> pure functional/denotative programming. > > I must say that I'm looking/reading your FRP stuff from the distance > thinking it's way above the head of this Haskell noob, but I tend to > agree that it should be possible to do GUI in Haskell in a different > way. > And not just a *different* way, but specifically a *denotative* way, i.e. in which our programs are built entirely out of pieces that have tractably precise meanings. I'm adopting this term "denotative" from Peter Landin's seminal paper "The Next 700 Programming Languages". See http://conal.net/blog/posts/is-haskell-a-purely-functional-language/#comment-35882. Previously I've been using the alternative "denotational". > Do you consider it can be achieved on the top of present libs like > wx/gtk+ or it would require writing new stuff? > I expect that even libraries like wx/gtk+ *can* be used as part of a faithful implementation of denotative GUI programming, if we take great care to insulate our denotation from the complex semantics of those libraries. However, this insulation may be so difficult to establish and maintain that it's easier to start from scratch. - Conal |
From: Gour <go...@go...> - 2010-01-23 21:15:19
Attachments:
signature.asc
|
On Sat, 23 Jan 2010 10:47:33 -0800 >>>>>> "Conal" == Conal Elliott wrote: Conal> I'm adopting this term "denotative" from Peter Landin's seminal Conal> paper "The Next 700 Programming Languages". See Conal> http://conal.net/blog/posts/is-haskell-a-purely-functional-language/#comment-35882. Conal> Previously I've been using the alternative "denotational". Thanks for the reference. Conal> I expect that even libraries like wx/gtk+ *can* be used as part Conal> of a faithful implementation of denotative GUI programming, if Conal> we take great care to insulate our denotation from the complex Conal> semantics of those libraries. However, this insulation may be so Conal> difficult to establish and maintain that it's easier to start Conal> from scratch. It would be good to be able to use those libs considering that Haskell community (at the moment) does not even have evenough man-power to adequately maintain language bindings, what to speak of developing & maintaining the whole toolkit. Otoh, I'm aware it won't come soon... Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: F96FF5F6 ---------------------------------------------------------------- |
From: Gour <go...@go...> - 2010-01-25 16:11:40
Attachments:
signature.asc
|
On Wed, 20 Jan 2010 18:35:08 +0000 >>>>>> "Jeremy" == "Jeremy O'Donoghue" wrote: Jeremy> I wish you luck in your decision, and will try to support you Jeremy> if you choose wxHaskell Let me just tell you that after being informed from the people working on Gtk-OSX project that "If OSX is an important platform for you, I strongly recommend you choose wx over gtk. Gtk's OSX support has gotten much better since last summer, but OSX is still very much an afterthought to the Gtk+ developers." and some more info, I've decided that we'll try to build our desktop GUI application using wxhaskell libs. Thanks everyone for all the input. Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: F96FF5F6 ---------------------------------------------------------------- |