On Wed, 29 Sep 2010 20:08:07 +0200, you wrote:

I think the problem is lack of Windows developers interested in GUIs, and that Windows is not so POSIXy-development-friendly as Linux or OS X. But mostly lack of people interested in that area, I think.

There are lots of Windows developers "interested" in GUIs. On the whole, I'd say that Windows developers are far more focused on GUIs than non-Windows developers. (See, for example: http://mpt.net.nz/archive/2008/08/01/free-software-usability and http://daringfireball.net/2004/04/spray_on_usability for some discussion of attitudes.) The issue isn't that there aren't a lot of Windows developers who have an interest in Haskell+GUI development. The issue is that nearly every Windows developer who looks into Haskell+GUI says, "This stuff sucks," and walks away, because they're interested in developing applications, not wrestling with GUI toolkits. -Steve Schafer

On 29 September 2010 20:33, Steve Schafer wrote:

There are lots of Windows developers "interested" in GUIs. [..]

The issue isn't that there aren't a lot of Windows developers who have an interest in Haskell+GUI development.

Yeah, what do you think I meant? We're talking about the state of Haskell GUI libraries, naturally I'm talking about Haskell GUI developers. Of course Windows developers are obsessed with GUIs, I can't get anything done in a terminal on Windows. (I'm exaggerating.)

The issue is that nearly every Windows developer who looks into Haskell+GUI says, "This stuff sucks," and walks away, because they're interested in developing applications, not wrestling with GUI toolkits.

Yeah, but not liking wrestling with libraries isn't peculiar to Haskell developers. There just needs to be enough people that the probability of there being a person who will bother to wrestle with it is high enough. Hence, the issue is lack of interest.

On 29 Sep 2010, at 20:34, Steve Schafer wrote:

This is an attitude that just doesn't fly in the Windows world. Which is unfortunate, because the Windows market is HUGE compared to OS X, and STUNNINGLY HUGE compared to everything else.

The fix isn't going to be to find a developer who's willing to do the work to make Haskell+GUI more seamless under Windows. The fix is for the Haskell community--as a whole--to wake up and realize what the wxWidgets folks did a while ago: "Hey, you know what? This GUI stuff is _important_ if we want people to pay any attention to the software that we write!"

This is why, when I developed my theorem prover, I put GUI aspects top of the list I chose wxHaskell because I wanted portability Ironically, given the thrust of this thread, I got it working without too much difficulty on Windows GHC 10.6.4, latest binaries for wxHaskell - easy to install and get working I gather several of my students have successfully done Linux builds of same I switched over recently to Mac OS X (10.6), and (more irony) am having real difficulties getting it to work - installing wxHaskell is a real bear on this platform.... The GUI theorem prover - see http://www.scss.tcd.ie/Andrew.Butterfield/Saoithin/ (I was going to announce this project to the Haskell Community real soon now, so I guess this is as good a time as any .....)

-Steve Schafer _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Wednesday 29 September 2010 23:02:02, Andrew Coppin wrote:

So anyway, that's the problem. The solution is...

Two obvious solutions. - stop using Windows and migrate to an OS where stuff works pretty much out of the box (not going to happen a lot) - start helping to make things work on Windows (maybe someday that will happen)

2010/9/30 Andrew Coppin :

And even then, your developed application will only run on Windows boxes that have GTK+ installed (i.e., none of them).

You can copy GTK+ DLLs with application. It works very well.

Apologies folks, rant coming up... On Wed, 29 Sep 2010 22:02 +0100, "Andrew Coppin" wrote:

On 29/09/2010 07:33 PM, Steve Schafer wrote:

...

The issue isn't that there aren't a lot of Windows developers who have an interest in Haskell+GUI development. The issue is that nearly every Windows developer who looks into Haskell+GUI says, "This stuff sucks," and walks away, because they're interested in developing applications, not wrestling with GUI toolkits.

Yep, that's the one.

[snip for brevity]

How do you do that in Haskell? Well, you can either install and configure a complete Unix emulator and then compile wxHaskell from source (?!), or you can use Gtk2hs, which still requires you to manually install and configure GTK+ and compile the entire library from source code. And even then, your developed application will only run on Windows boxes that have GTK+ installed (i.e., none of them). All of which is a far cry from "install IDE, click some buttons, run the wizzard, job done".

Then again, let us not claim that this is only a problem for GUI stuff. If you want to access a database, or run compression algorithms, or play sound, or do absolutely anything else which requires talking to C-land, you've going to have to face a world of pain on Windows.

As one of the people trying desperately to make this better on Windows (i.e. as wxHaskell maintainer...), I'd have to add that aspects of GHC make this much harder than I'd like. Take the specific case of wxHaskell, since I'm familiar with it. The 'requirement' is pretty straightforward in principle. What I want is: 1) Make wxHaskell easy to build and install on all platforms. 2) Make wxHaskell work in GHCi for 'exploratory' programming as well as for compiled executables Bear in mind that as I have a (very) demanding day job and a young family, I actually have no more than 3-4 hours a week (at best) to spend maintaining wxHaskell. Bear in mind also that my interest in wxHaskell was always to be able to develop software in Haskell, not fight with linkers and build systems (I get enough of that at work, thanks). While that's my personal problem, and others may not have the same issues, so please feel free to not care at all, it's worth bearing in mind... wxHaskell consists of a set of C bindings over the C++ core of wxWidgets. Broadly speaking, these unmangle the C++ names and do little else. Now, wxWidgets, being C++, links against libstdc++ (a not unreasonable requirement). MinGW, which is the underlying framework used by GHC only knows how to link libstdc++ statically, but the way cabal constructs link commands means that when wxcore gets loaded, GHCi attempts to load libstdc++ dynamically. You're dead. OK. Next step is to build the C wrapping as a separate DLL. In this case libstdc++ can be statically linked with the wxc DLL and the dependency on libstdc++ can go away. Trouble is, you now need to construct a C++ build system for a DLL in Cabal. Lots more custom build hooks, and some of what goes on under the hood is magic. However, eventually you get something which builds a DLL with only mildly sucky dependency management. Problem is now to pick this up in GHC and GHCi. After several weeks I still don't have the right stanza to invoke the linker. Next make sure that this all coexists with the inevitable several instances of MinGW, Cygwin and others which exist on the machine of a typical developer who uses Open Source code - ideally throwing in a nice mix of 32 and 64 bit variants of same, and with completely random path orderings. What would work best for me is something which is, I think, conceptually quite simple: allow Cabal to pull DLLs (or .so or .dylib or wwhatever) from some standard place (maybe in the Cabal tarball for a package), and add them to the link lines correctly, plus put them somewhere GHC will know about them for the future. This means that I, as wxHaskell developer, could build 'known good' wxWidgets DLLs, plus a known good wxc DLL and package them with wxcore, and end users would stop needing to care about building for themselves. This would let me use more appropriate build systems for the non-Haskell components without requiring users to download and install an insane number of libraries and developer tools - IOW, it puts the burden of building libraries on the library maintainer, but takes away the burden on the library maintainer of making this work for everyone else's machines, and documenting it, keeping the build documentation up to date and simple enough for people who don't want to become C or C++ developers to understand! As it is, in order to maintain what is a conceptually simple set of bindings, I need to become a deep expert in: - Customizing Cabal build hooks - How GHC and GHCi construct their link stanzas (is this documented anywhere?) - Installing and using MinGW - since this the only thing GHC guarantees to have available, so I'd like to use it to make life easier for others (much as I like gcc on Unix platforms, it's a long way from working as I'd expect on Windows) - MinGW quirks (like the inability to link libstdc++ as a DLL, and it's strange notion of import libraries) It would be nice if GHC and GHCi had a better story in respect of DLLs on Windows, but I accept that at least part of the problem is the underlying dependency on MinGW, so it's probably hard to solve this one.

It seems that because this stuff is such a PITA on Windows, nobody uses Haskell on Windows. And since nobody uses Haskell on Windows, nobody is fixing these problems. So they just stay here, forever.

Actually, I don't completely agree. I think that the issue is that making things better on Windows (and likely OS X as well) requires co-ordinated and agreed action across a number of areas. This means getting a moderate number of people, most of whom give up their time and effort for free, and for the good of the community, to agree on what is needed and to prioritize it in a co-ordinated way. The action needed by any individual might be relatively small, but without community agreement and action, the end goal cannot be achieved. Some areas probably need to be addressed by people whose primary focus *is* Linux (or other Unix) because that's what they use on a daily basis. They might well prefer to spend their valuable time on goals closer to their own hearts than in making life better on Windows, but the fact is that a better sotry on Windows probably does require some work in areas like GHC and Cabal, whose maintainers are, I suspect, mainly Linux users. Of course, the fact that this is all in the area of building and linking code, a notoriously revolting and unrewarding area of software development, and far less sexy than, say, inventing a morphism more unpronounceable than the Zygohistomorphic, probably doesn't help. Sorry for the rant, but just my $0.02 Regards Jeremy -- Jeremy O'Donoghue jeremy.odonoghue@gmail.com

Hello Heinrich, Saturday, October 2, 2010, 1:36:48 PM, you wrote:

Would you put a flattr button [1] on the wxHaskell page? This way, people like me would be able to show their appreciation by donating a

this page doesn't describe how to pay and how to got the money received. if Jeremy lives in "right" country, i suggest to use PayPal donations system. it allows to pay by credit card and then receive money to author's credit card PayPal provides you the donation button like one i used at http://freearc.org/Donations.aspx -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2010/10/2 Luke Palmer :

On Sat, Oct 2, 2010 at 4:32 AM, Bulat Ziganshin wrote:

...

Hello Heinrich,

Saturday, October 2, 2010, 1:36:48 PM, you wrote:

...

Would you put a flattr button [1] on the wxHaskell page? This way, people like me would be able to show their appreciation by donating a

this page doesn't describe how to pay and how to got the money received. if Jeremy lives in "right" country, i suggest to use PayPal donations system. it allows to pay by credit card and then receive money to author's credit card

Because of the way flattr distributes my money (i.e. donating has 0 marginal cost to me), I am much more likely to donate using flattr than paypal.

Is it right that by using flattr, you end up donating the same amount of money to every flattred person in a month? So you can donate more the previous month to some project you value less than another project the next month. This seems weird to me. Cheers, Thu

On Oct 2, 2010, at 3:30 PM, Peter Verswyvelen wrote:

Regarding GUIs, I really miss a pure functional framework for doing so.

Currently I'm using Microsoft's WPF, and that is more or less declarative, a bit like BOOPSI or MUI on the good old Amiga days. But WPF has so many little quirks, not to mentioned a weakly typed XML-like language called "XAML". Still it offers the best experiences I had so far, because it is very composable.

Are you using WPF with C# or F#? With F# it can feel pretty functional.

For another model of GUIs, see Tangible Values ( http://www.haskell.org/haskellwiki/TV), which is composable MVC. And amen to targeting GPUs. In addition to getting clunky, imperative GUI frameworks like wx & gtk working robustly and easily in Haskell across platforms, I'd love to see more powerful, functional-friendly re-thinking of UIs. And if a new generation of GUIs comes out scrapping legacy toolkits, and the look is not what people are used to, then exploiting GPUs and good visual design could lead to something that looks better and is more fun to use. I imagine someone looking at a lovely app and saying, "Wow -- great interface! I bet it was programmed in Haskell." - Conal On Sat, Oct 2, 2010 at 6:30 AM, Peter Verswyvelen wrote:

Regarding GUIs, I really miss a pure functional framework for doing so.

Currently I'm using Microsoft's WPF, and that is more or less declarative, a bit like BOOPSI or MUI on the good old Amiga days. But WPF has so many little quirks, not to mentioned a weakly typed XML-like language called "XAML". Still it offers the best experiences I had so far, because it is very composable.

What I would love is to build GUIs the Fruit/Yampa or maybe Reactive/Elerea way, using a graphical editor if possible. And allow separation of data (model and view-model) and looks (styling, CSS, themes...)

Oh and it should preferably make use of the GPU as much as possible, where it makes sense at least.

Anyway knows about such a framework in Haskell? It's a gigantic undertaking, but maybe if someone can make the basic framework, others in the community will develop controls for it?

Cheers, Peter Verswyvelen

On Sat, Oct 2, 2010 at 1:20 PM, Vo Minh Thu wrote:

...

2010/10/2 Luke Palmer :

...

On Sat, Oct 2, 2010 at 4:32 AM, Bulat Ziganshin wrote:

...

Hello Heinrich,

Saturday, October 2, 2010, 1:36:48 PM, you wrote:

...

Would you put a flattr button [1] on the wxHaskell page? This way, people like me would be able to show their appreciation by donating a

this page doesn't describe how to pay and how to got the money received. if Jeremy lives in "right" country, i suggest to use PayPal donations system. it allows to pay by credit card and then receive money to author's credit card

Because of the way flattr distributes my money (i.e. donating has 0 marginal cost to me), I am much more likely to donate using flattr than paypal.

Is it right that by using flattr, you end up donating the same amount of money to every flattred person in a month? So you can donate more the previous month to some project you value less than another project the next month. This seems weird to me.

Cheers, Thu _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Vo Minh Thu wrote:

Is it right that by using flattr, you end up donating the same amount of money to every flattred person in a month?

Yes.

So you can donate more the previous month to some project you value less than another project the next month. This seems weird to me.

That's the price of the vanishing marginal cost of flattr donations. :) But how about putting it this way: isn't it great that you no longer have to worry about attributing fair values to each project, since this cognitive burden would make you less likely of donating in the first place? ;) Personally, I revisit projects I value a lot every month anyway, which boils down to a larger share in the end. Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com

On 30/09/2010, at 7:08 AM, Christopher Done wrote:

On 29 September 2010 17:01, wrote:

...

I still cannot seem to get a GUI working under Windows.

For Haskell GUI's is Ubuntu easier to setup.

If so, we're losing people if Haskell GUI's are so hard to get working under Windows.

We're losing people! Charge!

I think the problem is lack of Windows developers interested in GUIs, and that Windows is not so POSIXy-development-friendly as Linux or OS X. But mostly lack of people interested in that area, I think.

I think we should put this in perspective. I teach a full-year 300-level software engineering paper. This year the students were required to design a project of their own and start to build it in Windows using C or C++. Then we switched them to Linux -- it's an education, not a picnic! For the final deliverable, they had to provide something I could run on one of the department's Macs running Linux. Welcome to DLL Hell. Of course I made a good faith attempt to try to install the libraries that they provided (if they did) but without superuser access there are limits; I also made a good faith attempt to download and build libraries they did not provide, but my patience has its limits and I wasn't prepared to spend more than an hour per assignment doing this. And of course there's the 64-bit -vs- 32-bit thing, where 32-bit programs are *supposed* to run on 64-bit Linux, but some of the 32-bit libraries required to make this actually work are missing... Unless you are willing to work at the level of Xt or possibly Lesstif, portability of GUI software on Linux in C or C++ does not come automatically; you have to work at it. Don't get me started on "everyone has the same kind of screen I do..."