The general consensus might be that "no-one wants gui libraries, as everything can be done on the web", but I think that's idiotic. Aside from e-mail, there's pretty much no "app" I use online but there are many desktop applications I use on a day to day basis, most written in C or C++, and a few written in Java, or Python. Various people have been claiming the death of the desktop for well over 10 years now, but I don't see it happening anytime soon. We've seen a lot of strong work going on in web-dev for Haskell, particularly in things like Yesod and Snap, but Haskell GUI development seems to be stagnating, and anytime anyone brings it up they get told "no one does GUI development anymore", which is complete BS or this issue wouldn't keep coming up. I've seen a few interesting GUI libraries, but they all seem to have died out for one reason or another, and if qtHaskell is actually being worked on and supported by someone I'd be very interested in finding out more about it. It would also be nice if some of the more interesting theoretical stuff like FRP could actually get a working example built on top of one of the current generation GUI libraries (I've looked at FRP a bit, but I don't really understand it, and I haven't found any FRP libraries that still work). -R. Kyle Murphy -- Curiosity was framed, Ignorance killed the cat. On Mon, Jun 27, 2011 at 08:45, Mats Rauhala wrote:

On 14:19 Mon 27 Jun , Øystein Kolsrud wrote:

...

I haven't had a look at any of the other libraries out there, so I don't really have much to compare with, but a problem with qtHaskell is that it's usage is very non-functional in nature, and a lot of it's C++ background shines through into the Haskell code (for instance management of constructors/destructors). But on the whole I am pretty happy with it.

That seems to be quite common with haskell GUI libraries. Even GTK is extremly imperative by nature, almost clear mapping between the C version and the Haskell version. The general concensus seems to be that 'no-one wants gui libraries, as everything can be done on the web' :/.

-- Mats Rauhala MasseR

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

I'm not sure to what degree qtHaskell is being worked on at the moment, but David Harley did answer some questions of mine per email so at least there is some level of support for it. /Øystein Kolsrud On Mon, Jun 27, 2011 at 9:25 PM, Kyle Murphy wrote:

The general consensus might be that "no-one wants gui libraries, as everything can be done on the web", but I think that's idiotic. Aside from e-mail, there's pretty much no "app" I use online but there are many desktop applications I use on a day to day basis, most written in C or C++, and a few written in Java, or Python. Various people have been claiming the death of the desktop for well over 10 years now, but I don't see it happening anytime soon. We've seen a lot of strong work going on in web-dev for Haskell, particularly in things like Yesod and Snap, but Haskell GUI development seems to be stagnating, and anytime anyone brings it up they get told "no one does GUI development anymore", which is complete BS or this issue wouldn't keep coming up. I've seen a few interesting GUI libraries, but they all seem to have died out for one reason or another, and if qtHaskell is actually being worked on and supported by someone I'd be very interested in finding out more about it. It would also be nice if some of the more interesting theoretical stuff like FRP could actually get a working example built on top of one of the current generation GUI libraries (I've looked at FRP a bit, but I don't really understand it, and I haven't found any FRP libraries that still work).

-R. Kyle Murphy -- Curiosity was framed, Ignorance killed the cat.

On Mon, Jun 27, 2011 at 08:45, Mats Rauhala wrote:

...

On 14:19 Mon 27 Jun     , Øystein Kolsrud wrote:

...

I haven't had a look at any of the other libraries out there, so I don't really have much to compare with, but a problem with qtHaskell is that it's usage is very non-functional in nature, and a lot of it's C++ background shines through into the Haskell code (for instance management of constructors/destructors). But on the whole I am pretty happy with it.

That seems to be quite common with haskell GUI libraries. Even GTK is extremly imperative by nature, almost clear mapping between the C version and the Haskell version. The general concensus seems to be that 'no-one wants gui libraries, as everything can be done on the web' :/.

-- Mats Rauhala MasseR

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

-- Mvh Øystein Kolsrud

On 10:11 Tue 28 Jun , Heinrich Apfelmus wrote:

wxHaskell intends to get into the Haskell Platform, but it needs more manpower. You can help!

http://comments.gmane.org/gmane.comp.lang.haskell.wxhaskell.devel/616

I'm actively working on FRP and have released the library

http://hackage.haskell.org/package/reactive-banana

If you have any suggestions, questions, needs for learning material, write me an email. Try the package and the developer blog

http://apfelmus.nfshost.com/blog.html#functional-reactive-programming-frp

and tell me of your learning journey; I'll figure out whether I should create a written tutorial, video tutorial or something else to help understand FRP.

The package

http://hackage.haskell.org/package/reactive-banana-wx

includes a tiny working example for wxHaskell .

Best regards, Heinrich Apfelmus

That seems promising. If you're really trying to get wxhaskell into Haskell Platform, it must be more mature than I initially thought. wxHaskell itself seems to be more functional than the GTK library I'm used to, which is enough motivation to try and learn it. Add to it the reactive-bananas library, and this might become something great. I initially had the idea that reactive-bananas was a little more than just a proof of concept, but seems like I was mistaken about that too :). Keep up the good work. -- Mats Rauhala MasseR

On 10:59 Wed 29 Jun , Heinrich Apfelmus wrote:

Indeed, reactive-banana intended to be a solid work horse. :) The FRP model is quite conservative because of this.

Of course, the library does cover new ground, nobody has figured out the most pleasant abstractions for dealing with common GUI tasks yet, but I'm in the process of finding some out.

I would like to encourage you to try it out and get back to me with any issues you have, both concerning documentation/learning and functionality. For instance, one of the authors of Leksah has experimented with it; while he had more ambitious plans than reactive-banana can handle at the moment, it prompted me to come up with the pleasing improvements in version 0.3. Not to mention that I now have a new use case to keep in mind for the big picture.

Personally, what I'd like is a simple documented tutorial/example for a simple application (counter which updates a label?), which is kept updated even when the library updates. I noticed two examples in the github repository, but I didn't have time to properly read them through yet. -- Mats Rauhala MasseR

Sorry, that wasn't intended, but to be fair I think it actually got hijacked pretty close the beginning as a "What's the state of GUI frameworks in Haskell?" thread. On the topic of qtHaskell I see that it's cross-platform which is good, but I also see where it doesn't appear to be compatible with the version of mingw that ships with GHC. The install instructions on the site tell you to overwrite the version of mingw in the ghc folder with the one shipped with qtHaskell which is a step I'm not willing to do currently. I haven't really looked at the API itself, but until either GHC or qtHaskell changes to not require overwriting the bundled mingw instance I'm going to have to take a pass on qtHaskell. I may try to install it without going through that step to see if it works anyway, although the comments about poor OpenGL performance also put me off a bit. -R. Kyle Murphy -- Curiosity was framed, Ignorance killed the cat. On Wed, Jun 29, 2011 at 11:00, David Virebayre wrote:

I'm sad that this qtHaskell thread was hijacked by wxHaskell.

David.

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

I've been really busy the last couple days and haven't had a chance to do more than look over reactive-banana, but I do recall looking at it previously and thinking it was a) really interesting looking, and b) I really need to go back through the typeclass-o-pedia because I don't really understand a lot of the types the core of it is built around. On the topic of wxWidgets, I really like the design of it, much more than GTK, which is part of the reason it was one of the first GUI libraries I tried to get working with Haskell. Unfortunately at the time (this was right around the transition to 6.12) I had all kinds of problems getting wxHaskell to work in Windows, even though it seemed to work well enough in Linux. At the time at least one of my key requirements was cross-platform support, so I had to abandon wxHaskell after I couldn't get it to work in Windows after more than a week of struggling with it. I've since managed to get GTK working cross-platform, but like others I've found it to be almost painfully procedural, and even then the process of getting it working was not exactly trivial. Once I get a little bit of time free I intend to try to get wxHaskell working in Windows again (hopefully now that 7.0 has stabilized a bit this should be a little smoother), and revisit reactive-banana. Worst case scenario maybe I'll at least get a better understanding of some of the more high level types out of it this time. -R. Kyle Murphy -- Curiosity was framed, Ignorance killed the cat. On Wed, Jun 29, 2011 at 02:39, Mats Rauhala wrote:

On 10:11 Tue 28 Jun , Heinrich Apfelmus wrote:

...

wxHaskell intends to get into the Haskell Platform, but it needs more manpower. You can help!

http://comments.gmane.org/gmane.comp.lang.haskell.wxhaskell.devel/616

I'm actively working on FRP and have released the library

http://hackage.haskell.org/package/reactive-banana

If you have any suggestions, questions, needs for learning material, write me an email. Try the package and the developer blog

http://apfelmus.nfshost.com/blog.html#functional-reactive-programming-frp

...

and tell me of your learning journey; I'll figure out whether I should create a written tutorial, video tutorial or something else to help understand FRP.

The package

http://hackage.haskell.org/package/reactive-banana-wx

includes a tiny working example for wxHaskell .

Best regards, Heinrich Apfelmus

That seems promising. If you're really trying to get wxhaskell into Haskell Platform, it must be more mature than I initially thought.

wxHaskell itself seems to be more functional than the GTK library I'm used to, which is enough motivation to try and learn it. Add to it the reactive-bananas library, and this might become something great. I initially had the idea that reactive-bananas was a little more than just a proof of concept, but seems like I was mistaken about that too :). Keep up the good work.

-- Mats Rauhala MasseR

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

On 6/28/11, Isak Hansen wrote:

On Fri, Jun 24, 2011 at 11:31 PM, Michael Serra wrote:

...

why do these bindings seem to be a less-popular option than wxwidgets and gtk2hs?

Licensing issues? -- http://qthaskell.berlios.de/doc/userGuide/license.html

Spending any effort learning a GPL library is a non-option for me.

Can anyone elaborate on this? Is there any way to (easily) separate code, so that your app isn't completely under GPL? Tom