Status of Haskell + Mac + GUIs & graphics

Conal Elliott

17 May 2011 17 May '11

7:24 p.m.

I still haven't found any way to do GUIs or interactive graphics in Haskell on a Mac that isn't plagued one or more of the following serious problems: * Incompatible with ghci, e.g., fails to make a window frame or kills the process the second time one opens a top-level window, * Goes through the X server, and so doesn't look or act like a Mac app, * Doesn't support OpenGL. A year or two ago, I put my Haskell GUI & graphics work on hold while waiting & hoping for a functioning pathway to open. So far I haven't heard of one. If anyone has found a solution, I'd love to hear! - Conal

Attachments:

attachment.html (text/html — 664 bytes)

Show replies by date

Tom Murphy

18 May 18 May

2:29 a.m.

...

I still haven't found any way to do GUIs or interactive graphics in Haskell on a Mac that isn't plagued one or more of the following serious problems:

* Incompatible with ghci, e.g., fails to make a window frame or kills the process the second time one opens a top-level window, * Goes through the X server, and so doesn't look or act like a Mac app, * Doesn't support OpenGL.

If there doesn't currently exist something without these handicaps, that's a serious problem for the use of Haskell for developing end-user software. If we as a community want to be able to develop software for end-users (i.e. people who'll be thrown off by gtk widgets or x11 windows)*, then it would be a very good idea to focus our energies on one or two promising pre-existing libraries, and hammer them into completion. A roadmap for this could be worked on at Hac Phi? Just my 2¢, Tom *This, of course, would NOT be avoiding success at all costs. :)

Jurriën Stutterheim

2:47 a.m.

A few weeks ago I set out to build a GUI app using wxHaskell. Long story short, we ditched the entire idea of a desktop GUI and went for a web application instead, because it was easier to develop a front-end for it and it was easier to style it. So here's my (perhaps slightly provoking) question: do we need to care at all about good GUI toolkits being available? Web applications, especially with an HTML 5 front-end, have become increasingly more powerful. If we can also find a good, standardized way to generate JS from our Haskell code, we're pretty much all set. Jurriën On 18 May, 2011, at 08:29 , Tom Murphy wrote:

...

...
I still haven't found any way to do GUIs or interactive graphics in Haskell on a Mac that isn't plagued one or more of the following serious problems:

* Incompatible with ghci, e.g., fails to make a window frame or kills the process the second time one opens a top-level window, * Goes through the X server, and so doesn't look or act like a Mac app, * Doesn't support OpenGL.

If there doesn't currently exist something without these handicaps, that's a serious problem for the use of Haskell for developing end-user software. If we as a community want to be able to develop software for end-users (i.e. people who'll be thrown off by gtk widgets or x11 windows)*, then it would be a very good idea to focus our energies on one or two promising pre-existing libraries, and hammer them into completion. A roadmap for this could be worked on at Hac Phi?

Just my 2¢, Tom

*This, of course, would NOT be avoiding success at all costs. :)

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

Michael Snoyman

2:51 a.m.

Along the same lines, once or twice I've needed to create a "desktop" version of a web app, which is what I wrote wai-handler-webkit[1] for. It only really builds properly on Linux for now, but if the need arises I don't see any reason it wouldn't work for Mac/Windows as well. Michael [1] http://hackage.haskell.org/package/wai-handler-webkit 2011/5/18 Jurriën Stutterheim :

...

A few weeks ago I set out to build a GUI app using wxHaskell. Long story short, we ditched the entire idea of a desktop GUI and went for a web application instead, because it was easier to develop a front-end for it and it was easier to style it. So here's my (perhaps slightly provoking) question: do we need to care at all about good GUI toolkits being available? Web applications, especially with an HTML 5 front-end, have become increasingly more powerful. If we can also find a good, standardized way to generate JS from our Haskell code, we're pretty much all set.

Jurriën

On 18 May, 2011, at 08:29 , Tom Murphy wrote:

...
...
I still haven't found any way to do GUIs or interactive graphics in Haskell on a Mac that isn't plagued one or more of the following serious problems:

* Incompatible with ghci, e.g., fails to make a window frame or kills the process the second time one opens a top-level window, * Goes through the X server, and so doesn't look or act like a Mac app, * Doesn't support OpenGL.

If there doesn't currently exist something without these handicaps, that's a serious problem for the use of Haskell for developing end-user software. If we as a community want to be able to develop software for end-users (i.e. people who'll be thrown off by gtk widgets or x11 windows)*, then it would be a very good idea to focus our energies on one or two promising pre-existing libraries, and hammer them into completion. A roadmap for this could be worked on at Hac Phi?

Just my 2¢, Tom

*This, of course, would NOT be avoiding success at all costs. :)

_______________________________________________ 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

Donn Cave

10:40 a.m.

Quoth =?iso-8859-1?Q?Jurri=EBn_Stutterheim?= , ...

...

So here's my (perhaps slightly provoking) question: do we need to care at all about good GUI toolkits being available? Web applications, especially with an HTML 5 front-end, have become increasingly more powerful. If we can also find a good, standardized way to generate JS from our Haskell code, we're pretty much all set.

That isn't so controversial - do we need to care about good GUI toolkits being available? Evidently not, we can say that from the fact that we're still looking for GUI support on the Mac in 2011. The Web application idea might be a useful workaround for some, like X11 may be acceptable for others, but these could be thought of as exceptions that prove the rule. If that's enough to solve the problem, then there would appear to be little call for Mac GUI applications. My only Haskell application on my ancient PPC Mac uses the terminal, but long ago I tried a Haskell Cocoa library, HOC, that would have supported native graphics, if it had worked for me. Has anyone taken that route with an application? I have been using native API graphics on another more obscure platform (Haiku), of course not portable but much easier to get working than the gigantic cross platform GUI toolkits, and maybe that would address the chicken vs egg problem that helps make Mac GUI apps a non-issue for Haskell. Donn

Tom Murphy

2:25 p.m.

On 5/18/11, Donn Cave wrote:

...

Quoth =?iso-8859-1?Q?Jurri=EBn_Stutterheim?= , ...

...
So here's my (perhaps slightly provoking) question: do we need to care at all about good GUI toolkits being available? Web applications, especially with an HTML 5 front-end, have become increasingly more powerful. If we can also find a good, standardized way to generate JS from our Haskell code, we're pretty much all set.

That isn't so controversial - do we need to care about good GUI toolkits being available? Evidently not, we can say that from the fact that we're still looking for GUI support on the Mac in 2011.

I'd give three reasons for disagreeing: 1. Developing a complete GUI has been a low priority up until now, but now that other, more urgent areas of development are starting to thrive, its time has come. 2. Yes, having essentially no complete GUI support has suited our needs up until now, but these have been the needs of a certain type of programmer. IF the community would like to grow, or would like to be able to use Haskell at work, I'd say a GUI supporting the above would be very valuable. 3. Using the web as Haskell's main method of non-command line (graphical) deployment seems to lose two of Haskell's most powerful features: its type safety, and its speed. If we use Haskell essentially as a JS abstraction layer, we lose all type safety (in the event that anyone goes in and tinkers with the generated JS). A main reason people are showing interest in FP is because of purity, and therefore its potential speed on multicore machines. If we just generate to JS, this is also lost. In fact, speed on single-core machines is lost also. Again, my 2¢, Tom

Stephen Tetley

3:29 p.m.

On 18 May 2011 19:25, Tom Murphy wrote:

...

I'd give three reasons for disagreeing: 1. Developing a complete GUI has been a low priority up until now, ...

I don't think that not having something as desireable good GUI suited anyone much, nor has it actually been a low priority - a lot of work has gone into the tools we have (and those that are now bit-rotted). It's more a case of an "industrial" level of effort is needed to develop and maintain a GUI solution. Java's Swing and Microsoft's Dot.Net had teams of programmers building them as loss leaders to establish their platforms. Similarly even GTK has had huge amount of resources invested in it.

Jurriën Stutterheim

4:23 p.m.

Regarding 3: I was not implying that Haskell should be used only for replacing JS. Far from it. I was just saying that we need a solid way to generate JS from Haskell so that we can profit even more from Haskell's type safety and not have to suffer from the mess that is JS. My Snap-based application is also perfectly type-safe, on the server. It's fast too. :) On 18 May, 2011, at 20:25 , Tom Murphy wrote:

...

On 5/18/11, Donn Cave wrote:

...
Quoth =?iso-8859-1?Q?Jurri=EBn_Stutterheim?= , ...

...
So here's my (perhaps slightly provoking) question: do we need to care at all about good GUI toolkits being available? Web applications, especially with an HTML 5 front-end, have become increasingly more powerful. If we can also find a good, standardized way to generate JS from our Haskell code, we're pretty much all set.

That isn't so controversial - do we need to care about good GUI toolkits being available? Evidently not, we can say that from the fact that we're still looking for GUI support on the Mac in 2011.

I'd give three reasons for disagreeing: 1. Developing a complete GUI has been a low priority up until now, but now that other, more urgent areas of development are starting to thrive, its time has come. 2. Yes, having essentially no complete GUI support has suited our needs up until now, but these have been the needs of a certain type of programmer. IF the community would like to grow, or would like to be able to use Haskell at work, I'd say a GUI supporting the above would be very valuable. 3. Using the web as Haskell's main method of non-command line (graphical) deployment seems to lose two of Haskell's most powerful features: its type safety, and its speed. If we use Haskell essentially as a JS abstraction layer, we lose all type safety (in the event that anyone goes in and tinkers with the generated JS). A main reason people are showing interest in FP is because of purity, and therefore its potential speed on multicore machines. If we just generate to JS, this is also lost. In fact, speed on single-core machines is lost also.

Again, my 2¢, Tom

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

Tom Murphy

4:51 p.m.

On 5/18/11, Jurriën Stutterheim wrote:

...

Regarding 3: I was not implying that Haskell should be used only for replacing JS. Far from it. I was just saying that we need a solid way to generate JS from Haskell so that we can profit even more from Haskell's type safety and not have to suffer from the mess that is JS. My Snap-based application is also perfectly type-safe, on the server. It's fast too. :)

Jurriën, I completely agree that we need a good JS generator. My response was just to the idea that web apps (with JS) could be a replacement for other GUI solutions. I wasn't implying you were saying we should only use Haskell for JS. Most useful Haskell apps right now are pretty GUI-free! Tom

wren ng thornton

11:01 p.m.

On 5/18/11 2:25 PM, Tom Murphy wrote:

...

I'd give three reasons for disagreeing: 1. Developing a complete GUI has been a low priority up until now, but now that other, more urgent areas of development are starting to thrive, its time has come. 2. Yes, having essentially no complete GUI support has suited our needs up until now, but these have been the needs of a certain type of programmer. IF the community would like to grow, or would like to be able to use Haskell at work, I'd say a GUI supporting the above would be very valuable. 3. Using the web as Haskell's main method of non-command line (graphical) deployment seems to lose two of Haskell's most powerful features: its type safety, and its speed.

I agree with these disagreements. Web apps have long been touted as a replacement for desktop apps. For certain specific kinds of domains people have been able to realize them sufficiently well as web apps. But I am still of the firm belief that there are numerous domains where browser-based UIs are wholly inappropriate. Thus, GUIs (especially OS-integrated GUIs) will remain a necessity for the foreseeable future. Moreover, for many people, the lack of native GUI support calls into question how mature and ready for serious work a language is; so developing a solid GUI story can be important publicity work. Beyond this, I can't say, since I rarely work on tools that require graphical interfaces. But I'd love to see a nice Cocoa--Haskell bridgework, since that's the kind of GUI I'm most liable to use/need. -- Live well, ~wren

KQ

25 May 25 May

11:37 a.m.

On Wed, 18 May 2011 20:01:48 -0700, wren ng thornton wrote:

...

3. Using the web as Haskell's main method of non-command line (graphical) deployment seems to lose two of Haskell's most powerful features: its type safety, and its speed. I agree with these disagreements. Web apps have long been touted as a replacement for desktop apps. For certain specific kinds of domains people have been able to realize them sufficiently well as web apps. But I am still of the firm belief that there are numerous domains where browser-based UIs are wholly inappropriate.

There are interesting scenarios where a "browser" is not required. I haven't worked with Snoyman's wai-handler-webkit which may be along these lines, but there's also https://developer.mozilla.org/en/xulrunner which provides the intriguing capability of an application that has (cross-platform) native-looking local windows but which can also interact via a (local or remote) browser. Clearly there's a gap between here and there, but part of that gap is the ability to simply and easily generate internal Javascript (to drive xulrunner) without actually programming in Javascript (it's just an API layer to the display, which is what I interpreted Jurriën Stutterheim's comments to be referring to). -- -KQ

Manuel M T Chakravarty

18 May 18 May

10:54 p.m.

Jurriën Stutterheim:

...

A few weeks ago I set out to build a GUI app using wxHaskell. Long story short, we ditched the entire idea of a desktop GUI and went for a web application instead, because it was easier to develop a front-end for it and it was easier to style it. So here's my (perhaps slightly provoking) question: do we need to care at all about good GUI toolkits being available? Web applications, especially with an HTML 5 front-end, have become increasingly more powerful. If we can also find a good, standardized way to generate JS from our Haskell code, we're pretty much all set.

For cross-platform apps, I have to agree. The effort required to build and maintain a cross-platform GUI toolkit is hard to justify given HTML 5 and related technologies. Nevertheless, there are good reasons to develop native applications (especially on the Mac with its user-base spoiled by high-end UX). Luckily, the choice of toolkit is trivial in this case. For Mac OS, we need a Haskell-Cocoa binding. I don't think there are any serious technical obstacles to develop one. Somebody would just have to spend the time and effort to write one. Manuel

...

On 18 May, 2011, at 08:29 , Tom Murphy wrote:

...
...
I still haven't found any way to do GUIs or interactive graphics in Haskell on a Mac that isn't plagued one or more of the following serious problems:

* Incompatible with ghci, e.g., fails to make a window frame or kills the process the second time one opens a top-level window, * Goes through the X server, and so doesn't look or act like a Mac app, * Doesn't support OpenGL.

If there doesn't currently exist something without these handicaps, that's a serious problem for the use of Haskell for developing end-user software. If we as a community want to be able to develop software for end-users (i.e. people who'll be thrown off by gtk widgets or x11 windows)*, then it would be a very good idea to focus our energies on one or two promising pre-existing libraries, and hammer them into completion. A roadmap for this could be worked on at Hac Phi?

Just my 2¢, Tom

*This, of course, would NOT be avoiding success at all costs. :)

_______________________________________________ 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

wren ng thornton

11:09 p.m.

On 5/18/11 10:54 PM, Manuel M T Chakravarty wrote:

...

Nevertheless, there are good reasons to develop native applications (especially on the Mac with its user-base spoiled by high-end UX). Luckily, the choice of toolkit is trivial in this case. For Mac OS, we need a Haskell-Cocoa binding. I don't think there are any serious technical obstacles to develop one. Somebody would just have to spend the time and effort to write one.

Well, there may be some non-trivial technical work in figuring out how to do good Haskell-like high-level bindings, rather than low-level bindings that shove everything into IO. Also, ensuring type safety across the border is extremely non-trivial, especially because Objective C's object system is on the untyped/Smalltalk end of things. It's possible to just treat their types like they do, but I'm sure many Haskellers would prefer to make the typing more explicit and checkable (so long as it's still usable). But yes, the mere process of making bindings isn't especially cumbersome. Anyone interested in prior art should take a look at the Perl--ObjectiveC bridgework, CamelBones: http://camelbones.sourceforge.net/ -- Live well, ~wren

Donn Cave

11:48 p.m.

Quoth wren ng thornton , ...

...

But yes, the mere process of making bindings isn't especially cumbersome. Anyone interested in prior art should take a look at the Perl--ObjectiveC bridgework, CamelBones:

http://camelbones.sourceforge.net/

Note (again) that there's already some work in this area, http://code.google.com/p/hoc/ My recollection from trying it several years ago was that there must indeed have been something especially cumbersome about it, given the prodigiously long time it would take to build an application, but it could be better now. In any case, I don't think it would be a crime to try a fresh start. With good Haskell-like high-level bindings, or not. If I were to work on it (as I was somewhat inspired to think about after reading Jason Dagit's comments), it would be the thinnest possible layer, with names unchanged and semantics preserved as possible. High level bindings can be applied on top of that, as required. Donn

Tom Murphy

19 May 19 May

midnight

On 5/18/11, Manuel M T Chakravarty wrote:

...

Nevertheless, there are good reasons to develop native applications (especially on the Mac with its user-base spoiled by high-end UX). Luckily, the choice of toolkit is trivial in this case. For Mac OS, we need a Haskell-Cocoa binding. I don't think there are any serious technical obstacles to develop one. Somebody would just have to spend the time and effort to write one.

Can anyone point me to a good resource comparing the pros and cons of developing (say, Cocoa) bindings vs. using a cross-platform library with native look-and-feel like Wx? Thanks, Tom

Heinrich Apfelmus

18 May 18 May

3:33 a.m.

Conal Elliott wrote:

...

I still haven't found any way to do GUIs or interactive graphics in Haskell on a Mac that isn't plagued one or more of the following serious problems:

* Incompatible with ghci, e.g., fails to make a window frame or kills the process the second time one opens a top-level window, * Goes through the X server, and so doesn't look or act like a Mac app, * Doesn't support OpenGL.

A year or two ago, I put my Haskell GUI & graphics work on hold while waiting & hoping for a functioning pathway to open. So far I haven't heard of one.

If anyone has found a solution, I'd love to hear!

I've asked a similar question on stackoverflow http://stackoverflow.com/questions/5868916/ and answered it myself. Basically, GLFW works (on my machine) as long as you don't call the GLFW.terminate function. The answer includes an example program that you can try out. It might be worth to include the extra hoops (EnableGUI) in the GLFW package. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com

Conal Elliott

3:21 p.m.

Thanks, Heinrich! I tried your sample code (having grabbed & compiled EnableGUI.hs). Works okay, including multiple calls to 'main'. There are a few subtle quirks. I don't see the usual bottom-right resize icon (three parallel lines at 45 degrees), and the Zooom/2 program for convenient window moving & resizing isn't able to move & resize this one window. Have you noticed something similar? - Conal On Wed, May 18, 2011 at 12:33 AM, Heinrich Apfelmus < apfelmus@quantentunnel.de> wrote:

...

Conal Elliott wrote:

...
I still haven't found any way to do GUIs or interactive graphics in Haskell on a Mac that isn't plagued one or more of the following serious problems:

* Incompatible with ghci, e.g., fails to make a window frame or kills the process the second time one opens a top-level window, * Goes through the X server, and so doesn't look or act like a Mac app, * Doesn't support OpenGL.

A year or two ago, I put my Haskell GUI & graphics work on hold while waiting & hoping for a functioning pathway to open. So far I haven't heard of one.

If anyone has found a solution, I'd love to hear!

I've asked a similar question on stackoverflow

http://stackoverflow.com/questions/5868916/

and answered it myself. Basically, GLFW works (on my machine) as long as you don't call the GLFW.terminate function. The answer includes an example program that you can try out.

It might be worth to include the extra hoops (EnableGUI) in the GLFW package.

Best regards, Heinrich Apfelmus

-- http://apfelmus.nfshost.com

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

Heinrich Apfelmus

3:59 p.m.

Conal Elliott wrote:

...

Thanks, Heinrich!

I tried your sample code (having grabbed & compiled EnableGUI.hs). Works okay, including multiple calls to 'main'.

There are a few subtle quirks. I don't see the usual bottom-right resize icon (three parallel lines at 45 degrees), and the Zooom/2 program for convenient window moving & resizing isn't able to move & resize this one window. Have you noticed something similar?

Indeed, same problem here. While I can resize the window, it doesn't show the corresponding icon. (I don't use Zooom/2.) This seems to be a problem with the GLFW library; you may want to file a bug report. I glean from Apple's documentation that a a judicious call to [window setShowsResizeIndicator:TRUE] at the time of window creation might solve the problem. Cocoa is always a little unpredictable when creating UI elements from scratch. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com

Sam Martin

4:18 a.m.

Is there a library that satisfies 2 of your 3 points? * Works with ghci * Supports OpenGL. I've struggled to get: * A window with opengl * Running interactively from ghci * Working cross platform Anyone know of a solution for that? If there's a library that handles that, then there's at least a sensible base to build a pure functional GUI system on. Cheers, Sam From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Conal Elliott Sent: 18 May 2011 00:24 To: Haskell Cafe Subject: [Haskell-cafe] Status of Haskell + Mac + GUIs & graphics I still haven't found any way to do GUIs or interactive graphics in Haskell on a Mac that isn't plagued one or more of the following serious problems: * Incompatible with ghci, e.g., fails to make a window frame or kills the process the second time one opens a top-level window, * Goes through the X server, and so doesn't look or act like a Mac app, * Doesn't support OpenGL. A year or two ago, I put my Haskell GUI & graphics work on hold while waiting & hoping for a functioning pathway to open. So far I haven't heard of one. If anyone has found a solution, I'd love to hear! - Conal

Andrew Butterfield

4:18 a.m.

I have developed a GUI app using wxHaskell I develop using GHCi - invaluable I can run the application once form GHCi, and then a re-run crashes, but - usually after a run there is enough time to re-start GHCi while I tihnk about what needs fixing next - usually I can still run tests and queries from GHCi afterwards... This works because I develop in Windows using GHC 6.10.4 wxHaskell 0.11.1.2 - I haven't upgraded because I believe the GHCi behaviour worsens on later versions of GHC (I'm open to correction on this) - a student of mine has been able to build it on linux using the latest versions of everything - I had to revise some of my code simply because later GHC versions introduced new keywords So - to summarise If you are happy to develop using 6.10.4, on Windows then wxHaskell is workable with GHCi It seems to then build ok on Linux Alas - I have yet to be able to build it on Mac OS X (Snow Leopard) The app ? - see http://www.scss.tcd.ie/Andrew.Butterfield/Saoithin/ On 18 May 2011, at 00:24, Conal Elliott wrote:

...

I still haven't found any way to do GUIs or interactive graphics in Haskell on a Mac that isn't plagued one or more of the following serious problems:

* Incompatible with ghci, e.g., fails to make a window frame or kills the process the second time one opens a top-level window, * Goes through the X server, and so doesn't look or act like a Mac app, * Doesn't support OpenGL.

A year or two ago, I put my Haskell GUI & graphics work on hold while waiting & hoping for a functioning pathway to open. So far I haven't heard of one.

If anyone has found a solution, I'd love to hear!

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

-------------------------------------------------------------------- Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204 Foundations and Methods Research Group Director. School of Computer Science and Statistics, Room F.13, O'Reilly Institute, Trinity College, University of Dublin http://www.cs.tcd.ie/Andrew.Butterfield/ --------------------------------------------------------------------

Eric Y. Kow

11:53 a.m.

New subject: wxHaskell on Mac (Was: Status of Haskell + Mac + GUIs & graphics)

Hi On Wed, May 18, 2011 at 09:18:42 +0100, Andrew Butterfield wrote:

...

Alas - I have yet to be able to build it on Mac OS X (Snow Leopard)

For what it's worth, I'm still using wxHaskell on MacOS X (also Snow Leopoard) The tricky bits are that you have to 1. install wxWidgets by hand, being sure to enable Unicode and to compile a 32 bit version: arch_flags="-arch i386" ./configure CFLAGS="$arch_flags"\ CXXFLAGS="$arch_flags"\ CPPFLAGS="$arch_flags"\ LDFLAGS="$arch_flags"\ OBJCFLAGS="$arch_flags"\ OBJCXXFLAGS="$arch_flags"\ --enable-unicode 2. do the Rez and app bundle magic which is now handily encapsulated in the cabal-macosx package on hackage I also have patches to make it work with the latest Haskell Platform and will put them on Hackage shortly assuming nobody objects darcs get --lazy http://darcsden.com/kowey/wxhaskell Unfortunately, this does not address Conal's issue about using wxHaskell with GHCi on Mac. I do wish somebody had a free week to concentrate on the issue. Maintainer Jeremy made some progress on it, the last time I checked... -- Eric Kow http://erickow.com

Tom Murphy

3:06 p.m.

New subject: wxHaskell on Mac (Was: Status of Haskell + Mac + GUIs & graphics)

...

The tricky bits are that you have to

1. install wxWidgets by hand, being sure to enable Unicode and to compile a 32 bit version:

arch_flags="-arch i386" ./configure CFLAGS="$arch_flags"\ CXXFLAGS="$arch_flags"\ CPPFLAGS="$arch_flags"\ LDFLAGS="$arch_flags"\ OBJCFLAGS="$arch_flags"\ OBJCXXFLAGS="$arch_flags"\ --enable-unicode

Is there a way to build an installer that would make this process easier?

...

Unfortunately, this does not address Conal's issue about using wxHaskell with GHCi on Mac. I do wish somebody had a free week to concentrate on the issue. Maintainer Jeremy made some progress on it, the last time I checked...

Do you have the link for the progress so far? Tom

Eric Y. Kow

7:03 p.m.

New subject: wxHaskell on Mac (Was: Status of Haskell + Mac + GUIs & graphics)

On Wed, May 18, 2011 at 15:06:02 -0400, Tom Murphy wrote:

...

Is there a way to build an installer that would make this process easier?

I've sent a pull request to the maintainer of homebrew. Hopefully it should then just be a matter of brew install wxmac Homebrew's wxWidgets already builds 32 bit, but it omitted the enable-unicode, which is what my patch fixes)

...

...
Unfortunately, this does not address Conal's issue about using wxHaskell with GHCi on Mac. I do wish somebody had a free week to concentrate on the issue. Maintainer Jeremy made some progress on it, the last time I checked...

Do you have the link for the progress so far?

Jeremy's blog seems to talk about this: http://wewantarock.wordpress.com/ I remember that the impression that Brian Lewis was also looking into this at some point http://www.mail-archive.com/wxhaskell-users@lists.sourceforge.net/msg00744.h... If anybody knows what this "unknown symbol `__dso_handle'" means and what we can do about it, it could be a great help I wonder if GHC 7 makes any of this easier... -- Eric Kow http://erickow.com

Jeremy O'Donoghue

20 May 20 May

10:57 a.m.

New subject: wxHaskell on Mac (Was: Status of Haskell + Mac + GUIs & graphics)

On 19 May 2011 00:03, Eric Y. Kow wrote:

...

On Wed, May 18, 2011 at 15:06:02 -0400, Tom Murphy wrote:

...
Is there a way to build an installer that would make this process easier?

I've sent a pull request to the maintainer of homebrew. Hopefully it should then just be a matter of brew install wxmac

Homebrew's wxWidgets already builds 32 bit, but it omitted the enable-unicode, which is what my patch fixes)

...
...
Unfortunately, this does not address Conal's issue about using wxHaskell with GHCi on Mac. I do wish somebody had a free week to concentrate on the issue. Maintainer Jeremy made some progress on it, the last time I checked...

Do you have the link for the progress so far?

Jeremy's blog seems to talk about this: http://wewantarock.wordpress.com/

I remember that the impression that Brian Lewis was also looking into this at some point

http://www.mail-archive.com/wxhaskell-users@lists.sourceforge.net/msg00744.h...

If anybody knows what this "unknown symbol `__dso_handle'" means and what we can do about it, it could be a great help

It is a handle for a dynamic shared object. It is required for the case where __cxa_atexit() is called, which is when a shared library is unloaded. It is specifically required because there are C++ statics on which destructors should be called. The documentation says that __dso_handle should be unique to the shared library instance.

...

I wonder if GHC 7 makes any of this easier...

GHC7 may (should) fix the problem linking libstdc++.dll on Windows. The static destructor problem probably requires 'true' dynamic loading and unloading of the wxWidgets DLL from within part of the wxcore wrapper code. Loading wxwidgets dll with dlopen() (Unix) or LoadLibrary() (Windows) will give us a DLL handle, and unloading with dlclose()/UnloadLibrary() will ensure that the destructors are called. The problem is that doing this means that you only know the address of wrapper functions after they have been loaded (need to do a dlsym()/GetProcAddr() to fetch this info), and doing this for the several thousand functions in wxHaskell will require some automation to extract the information to generate the code to do this. The code should probably live in wxDirect, but I loose the will to live whenever I go digging there :-( Regards Jeremy

Jason Dagit

18 May 18 May

2:09 p.m.

On Tue, May 17, 2011 at 4:24 PM, Conal Elliott wrote:

...

I still haven't found any way to do GUIs or interactive graphics in Haskell on a Mac that isn't plagued one or more of the following serious problems:

* Incompatible with ghci, e.g., fails to make a window frame or kills the process the second time one opens a top-level window, * Goes through the X server, and so doesn't look or act like a Mac app, * Doesn't support OpenGL.

Support for OpenGL comes in different levels of quality, as I'm discovering. It would seem that Mesa (ie., linux support), only officially supports OpenGL 2.1 [1] despite being released on 6 April 2011. I haven't been able to get OpenGL 3.0+ specific features to work on linux with Haskell yet. I find that you really want OpenGL 3.1 or newer. The Khronos group really did a lot of nice things with the 3.x specification and 4.x is even better. Some people in this thread have suggested doing web apps. This won't work well yet for people who want OpenGL support. My experiments with webgl show that it's not mature yet. You have to target a specific browser and OS at the moment, with linux having the worst support by far. Firefox 4 and Chrome on windows fair the best so far.

...

A year or two ago, I put my Haskell GUI & graphics work on hold while waiting & hoping for a functioning pathway to open. So far I haven't heard of one.

Yes, I know the feeling all too well. I'd like to fix this situation. I took over maintainership of the Haskell OpenGL bindings hoping that I could improve them. We now have a google summer of code student working on the bindings to update them and improve the overall quality. That's just one piece of the puzzle. If you'd like to contribute to that piece of the puzzle we have an organization on github for Haskell OpenGL: https://github.com/haskell-opengl Send some pull requests or add bug tickets! As you point out we also need better libraries for creating the OpenGL context. I wrote up my searches on that front here: http://blog.codersbase.com/2011/03/picking-gui-library-to-use-with-opengl.ht... My conclusion was that GLFW-b (on hackage) is the best we have right now. I think we could do even better than the C libraries out there by writing the GLUT/GLFW/etc implementation purely in Haskell. We already have x11 and gtk bindings for the linux support. We have win32 api bindings for windows support. What we are lacking is good low level support for OSX GUI programming. Once we have that it's not too much of a stretch to use cabal to glue it together into a cross platform library. I believe that's the right way to go for the long term. Improving GLFW-b is a good short-term route. And just to say it one more time, I can use all the help I can get. There are a lot of yaks to be shaved. My hope is that if we all shave one yak then we'll quickly have the libraries we need to do some serious graphics hacking in Haskell. We already have many good libraries for it, we just need to improve and polish a few key libraries. The momentum is here and a few people have already jumped in. Time to get on board! Jason

Jason Dagit

2:10 p.m.

On Wed, May 18, 2011 at 11:09 AM, Jason Dagit wrote:

...

Support for OpenGL comes in different levels of quality, as I'm discovering. It would seem that Mesa (ie., linux support), only officially supports OpenGL 2.1 [1] despite being released on 6 April 2011. I haven't been able to get OpenGL 3.0+ specific features to work on linux with Haskell yet.

[1] http://www.mesa3d.org/relnotes-7.10.2.html Sorry, I forgot the link! Jason

Tom Murphy

2:42 p.m.

...

My conclusion was that GLFW-b (on hackage) is the best we have right now. I think we could do even better than the C libraries out there by writing the GLUT/GLFW/etc implementation purely in Haskell. We already have x11 and gtk bindings for the linux support. We have win32 api bindings for windows support. What we are lacking is good low level support for OSX GUI programming. Once we have that it's not too much of a stretch to use cabal to glue it together into a cross platform library. I believe that's the right way to go for the long term. Improving GLFW-b is a good short-term route.

Would it be possible to do it with wx? There would be a much larger potential developer pool, since it's cross-platform. (Not getting away from C libraries, but they're stable).

...

And just to say it one more time, I can use all the help I can get. There are a lot of yaks to be shaved. My hope is that if we all shave one yak then we'll quickly have the libraries we need to do some serious graphics hacking in Haskell. We already have many good libraries for it, we just need to improve and polish a few key libraries. The momentum is here and a few people have already jumped in. Time to get on board!

Count me as onboard; I'm just not sure which ship I'm on yet. Tom

Conal Elliott

3:33 p.m.

Last I heard, wx still had the problem of crashing its host the second time one opens a window (which is typical in ghci). And last I heard, Jeremy O'Donoghue (cc'd) was exploring solutions but had very little time to pursue them. - Conal On Wed, May 18, 2011 at 11:42 AM, Tom Murphy wrote:

...

...
My conclusion was that GLFW-b (on hackage) is the best we have right now. I think we could do even better than the C libraries out there by writing the GLUT/GLFW/etc implementation purely in Haskell. We already have x11 and gtk bindings for the linux support. We have win32 api bindings for windows support. What we are lacking is good low level support for OSX GUI programming. Once we have that it's not too much of a stretch to use cabal to glue it together into a cross platform library. I believe that's the right way to go for the long term. Improving GLFW-b is a good short-term route.

Would it be possible to do it with wx? There would be a much larger potential developer pool, since it's cross-platform. (Not getting away from C libraries, but they're stable).

...
And just to say it one more time, I can use all the help I can get. There are a lot of yaks to be shaved. My hope is that if we all shave one yak then we'll quickly have the libraries we need to do some serious graphics hacking in Haskell. We already have many good libraries for it, we just need to improve and polish a few key libraries. The momentum is here and a few people have already jumped in. Time to get on board!

Count me as onboard; I'm just not sure which ship I'm on yet.

Tom

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

Heinrich Apfelmus

19 May 19 May

9:01 a.m.

Conal Elliott wrote:

...

Last I heard, wx still had the problem of crashing its host the second time one opens a window (which is typical in ghci). And last I heard, Jeremy O'Donoghue (cc'd) was exploring solutions but had very little time to pursue them. - Conal

Last I remember, the latest problem is that ghci is unable to link libstdc++. But the crash problem is probably still there. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com

John Lask

8:23 p.m.

On 19/05/2011 10:31 PM, Heinrich Apfelmus wrote: my comments for what their worth: (1) wx and ghci: I successfully run wx in ghci (albeit) on windows. I take an alternative path to that proscribed by the current build process - I think principally so that I am able to run it in ghci, although I can not now recall the exact reason why I took the different route. The current build process links the haskell wxcore library against the wxwdigets libraries directly. Once upon a time, the wxlibraries were wrapped as a C (dll) library, and the haskell libraries linked against this. I choose this route, and have no problems loading wxwdigets applications in ghci (on windows) ... and using OpenGL with them. (2) on the question of GUI libraries in general. I remind readers that the discussion of a GUI for haskell is no new thing, (cf. GUI API Taskforce) http://www.haskell.org/pipermail/haskell/2001-September/007960.html http://comments.gmane.org/gmane.comp.lang.haskell.gui/7 ... and many more ... a lot of which has been said recently, has been said before (it does not make it less relevant, though) ... there are two very different responses, the tactical and the strategic, they generally have very different time frames and cost (effort) required. A tactical response might be to ensure that one of the (many) currently existing libraries (wxHaskell, qtHaskell, hs-fltk...) built and operated problem free on all platforms. Whereas, a strategic response might be to have a cross platform gui library binding to low level platform libraries (Win32, X11, Cocoa) Of course there are all sorts of variants in between. A general problem with strategic response is they underestimate the effort required due to the long range horizon and the uncertainties involved. if the question is what will provide me with the tools that I need today or tomorrow, which is the more efficacious response?

...

Conal Elliott wrote:

...
Last I heard, wx still had the problem of crashing its host the second time one opens a window (which is typical in ghci). And last I heard, Jeremy O'Donoghue (cc'd) was exploring solutions but had very little time to pursue them. - Conal

Last I remember, the latest problem is that ghci is unable to link libstdc++. But the crash problem is probably still there.

Best regards, Heinrich Apfelmus

-- http://apfelmus.nfshost.com

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

Felipe Almeida Lessa

8:32 p.m.

On Thu, May 19, 2011 at 9:23 PM, John Lask wrote:

...

A general problem with strategic response is they underestimate the effort required due to the long range horizon and the uncertainties involved.

The efforts in building a cross-platform GUI are not to be underestimated. Otherwise nobody would have problems in using Gtk/Qt/Wx, all three well-developed by many hands. IMHO, if you want programs with native look & feel on many platforms, separate internal code from the GUI code and make one GUI for Windows, another GUI using Gtk, another one using Qt and another one using Cocoa (example [1]). Even if your toolkit was perfect, platforms have different practices and cultures that should be accounted for. Cheers =), [1] http://www.transmissionbt.com/ -- Felipe.

Evan Laforge

9:48 p.m.

On Thu, May 19, 2011 at 5:32 PM, Felipe Almeida Lessa wrote:

...

On Thu, May 19, 2011 at 9:23 PM, John Lask wrote:

...
A general problem with strategic response is they underestimate the effort required due to the long range horizon and the uncertainties involved.

The efforts in building a cross-platform GUI are not to be underestimated. Otherwise nobody would have problems in using Gtk/Qt/Wx, all three well-developed by many hands.

Maybe I'm underestimating, but from working with fltk it doesn't seem that bad. It seems very daurting if you look at giant toolkits like gtk, but the entire cocoa backend for fltk is just 3,500 lines of objective C++. The entire library is about 100k lines (via wc) including headers, comments, doxygen, blank lines, etc. and I only use a fraction of that. Do it in the worlds best imperative language, implement only the widgets I need, and do it in a more high level and modern style, and omit stuff I don't like like DnD :), and it doesn't seem very scary to me. It's not going to have native look and feel since the OS level just provides drawing primitives (otherwise I think it would be a really complicated interface with lots of OS level differences), but it provides access to the underlying window pointer so you can add a native file chooser (as fltk does), etc. I think the main thing would be not trying to support all GUI features, just simple ones. If I had a lot of GUI enthusiasm and no other project I would be tempted to just try it.

...

IMHO, if you want programs with native look & feel on many platforms, separate internal code from the GUI code and make one GUI for Windows, another GUI using Gtk, another one using Qt and another one using Cocoa (example [1]). Even if your toolkit was perfect, platforms have different practices and cultures that should be accounted for.

I like this approach too. I write the GUI in c++ and then export a medium level C API of only 10-20 functions and FFI it. I use fltk, but if I really cared about the GUI then I could write native backends for each platform. If you really want to put a lot of effort into the GUI and have it just right, I think it's the only option. However, we could still have a library that provided a standard for things like event types and event loop utilities. And I think for GUIs that don't have to be native and have fancy features, there is still a place for a simple cross platform GUI library.

Jeremy O'Donoghue

20 May 20 May

11:35 a.m.

On 20 May 2011 02:48, Evan Laforge wrote:

...

On Thu, May 19, 2011 at 5:32 PM, Felipe Almeida Lessa wrote:

...
On Thu, May 19, 2011 at 9:23 PM, John Lask wrote:

...
A general problem with strategic response is they underestimate the effort required due to the long range horizon and the uncertainties involved.

The efforts in building a cross-platform GUI are not to be underestimated. Otherwise nobody would have problems in using Gtk/Qt/Wx, all three well-developed by many hands.

Maybe I'm underestimating, but from working with fltk it doesn't seem that bad. It seems very daurting if you look at giant toolkits like gtk, but the entire cocoa backend for fltk is just 3,500 lines of objective C++.

It isn't hard (for the most part) but it is tedious. For most of the time I have been working on wxHaskell, the core issue has been getting the thing to build and install, repeatably, on machines with different OS versions, tools and the like. In the case of wxHaskell, the progression has been (approximately) - Older versions use a make based build system. This was very fragile when it came to supporting multiple platforms, although it had the benefit of being very flexible, and supporting some options we don't support now. Biggest problem was that every new user would spend hours fighting to get the thing to build (as would I if I hadn't looked at it for a while). - Move to a partial cabal/make system. This built the Haskell components using cabal and the C++ components using make. Still too fragile for most users, and didn't fulfill the itch to allow 'cabal install wx'. - Move to a fully cabalized system. This has essentially required us to build a C++ build system in custom Cabal build stanzas. Notice - nothing hard in any of the above, but not much fun either. It's mainly about dealing with obscure link errors and platform issues. Generally adding extra functions is the work of just a few minutes!

...

Do it in the worlds best imperative language, implement only the widgets I need, and do it in a more high level and modern style, and omit stuff I don't like like DnD :), and it doesn't seem very scary to me.

Hmm. I guess we will need to get the entire Haskell GUI world to agree on which functionality is 'useful' and/or 'liked'. You quickly find that the union of minimum 'essential' functionality is 'almost everything'. Even the 'simple' GUI features will turn out to involve many function calls.

...

...
IMHO, if you want programs with native look & feel on many platforms, separate internal code from the GUI code and make one GUI for Windows, another GUI using Gtk, another one using Qt and another one using Cocoa (example [1]). Even if your toolkit was perfect, platforms have different practices and cultures that should be accounted for.

I like this approach too. I write the GUI in c++ and then export a medium level C API of only 10-20 functions and FFI it. I use fltk, but if I really cared about the GUI then I could write native backends for each platform. If you really want to put a lot of effort into the GUI and have it just right, I think it's the only option.

Actually, toolkits like wx and Qt go to a lot of trouble to deal with most platform practices and cultures. While I agree in principle that writing the GUI directly in a platform toolkit will give the best results (at least aesthetically), it has its downsides. For example, to write a moderately complex GUI for a program supporting Windows, Mac and Linux would require me to put together GUIs in C# (Windows WPF, for example), C (Gtk) and Objective C. It is far from a trivial undertaking to learn enough of any of these to produce a GUI which is significantly better than wx would product out of the box, using the same source code for all platforms. However... if you are willing to make such an effort, it is absolutely going to produce better results than a cross-platform toolkit. Having said that, I believe that there is a 'market' for a GUI toolkit which is capable of producing good quality results - very close to native on all platforms - from one piece of source code. The problem, as I see it, is that: - Doing a cross-platform GUI library for Haskell based on one of the major libraries is somewhat tedious for the most part. No one will be able to brag about their awesome type hackery... - Proof is that wxHaskell is basically me, with specific contributions (some awesome) from others. I have the impression that GtkHS has a similarly small core team. - You need pretty good C or C++ and linker skills. Haskell skills are actually less important. - The size of the community means that fragmenting effort across multiple GUI platforms is a mistake. If there were 10 people each contributing significantly to wxHaskell, GtkHS and QtHaskell, we would have every reason to support them all. - Of course, there are many reasons: licensing, general preference, primary platform used for development, religion etc. why people favour one or other toolkit. The problem is that I don't think we have the luxury of supporting them all. - E.g. my *primary* reason for choosing wxHaskell (over GtkHS) 5 years back was licensing. The detailed reasons are OT here. - Other will have other reasons - probably no less valid than my own. - What everyone would *really* like is a less 'imperative' style of GUI programming. It's true that wxHaskell, GtkHS and so on basically let you do type safe C programming. This *does* need the uber type hackers and Haskell experts, but work in this direction has been equally stifled by the fact that the GUI bindings like wxHaskell tend not to get enough love to fix issues they are seeing. I would like to suggest, quite seriously, that the Haskell community try to come to a consensus about supporting a single Haskell GUI, with a view to distribution in the HP. Obviously my vote is for wxHaskell, but I'm quite prepared to loose the vote. Reason is that I think we need to concentrate some effort on getting one GUI binding to 'production' status, and I don't believe that on the current basis we will ever do this. From my perspective, only GtkHS and wxHaskell look like serious candidates with at least some history and maturity behind them. Best regards Jeremy

Gregory Crosswhite

2:39 p.m.

On 5/20/11 8:35 AM, Jeremy O'Donoghue wrote:

...

I would like to suggest, quite seriously, that the Haskell community try to come to a consensus about supporting a single Haskell GUI, with a view to distribution in the HP. Obviously my vote is for wxHaskell, but I'm quite prepared to loose the vote. Reason is that I think we need to concentrate some effort on getting one GUI binding to 'production' status, and I don't believe that on the current basis we will ever do this. From my perspective, only GtkHS and wxHaskell look like serious candidates with at least some history and maturity behind them.

If you are going to rule out Qt, then the only good cross-platform option remaining is wx since Gtk is not fully native on OSX but instead uses X11 which results in an inferior user experience, and it would be a bad idea to have that be the standard that everyone associates with applications written in Haskell. Cheers, Greg

Erik Hesselink

6:50 p.m.

On Fri, May 20, 2011 at 20:39, Gregory Crosswhite wrote:

...

On 5/20/11 8:35 AM, Jeremy O'Donoghue wrote:

...
I would like to suggest, quite seriously, that the Haskell community try to come to a consensus about supporting a single Haskell GUI, with a view to distribution in the HP. Obviously my vote is for wxHaskell, but I'm quite prepared to loose the vote. Reason is that I think we need to concentrate some effort on getting one GUI binding to 'production' status, and I don't believe that on the current basis we will ever do this. From my perspective, only GtkHS and wxHaskell look like serious candidates with at least some history and maturity behind them.

If you are going to rule out Qt, then the only good cross-platform option remaining is wx since Gtk is not fully native on OSX but instead uses X11 which results in an inferior user experience, and it would be a bad idea to have that be the standard that everyone associates with applications written in Haskell.

Note that it is supposed to be possible to build gtk2hs with gtk+osx, which will not use X11 but use the native OS X GUI. I've not been able to get this to work, but it's been a while since I tried. The Haskell wiki mentions it doesn't support Glade, but does support Cairo. If this were to work, gtk2hs would be a serious option as well. Erik

Evan Laforge

6:59 p.m.

...

Note that it is supposed to be possible to build gtk2hs with gtk+osx, which will not use X11 but use the native OS X GUI. I've not been able to get this to work, but it's been a while since I tried. The Haskell wiki mentions it doesn't support Glade, but does support Cairo. If this were to work, gtk2hs would be a serious option as well.

I've tried this 3 or 4 times, and failed every time. It's crazy complicated.

murray＠sonology.net

21 May 21 May

9:23 a.m.

On 2011-05-20, Evan Laforge wrote:

...

...
Note that it is supposed to be possible to build gtk2hs with gtk+osx, which will not use X11 but use the native OS X GUI. I've not been able to get this to work, but it's been a while since I tried. The Haskell wiki mentions it doesn't support Glade, but does support Cairo. If this were to work, gtk2hs would be a serious option as well.

I've tried this 3 or 4 times, and failed every time. It's crazy complicated.

A couple of months ago I succeeded in installing gtk2hs like this on a Snow Leopard MacBook Air and it seemed to work pretty well. It was indeed a fairly involved process but it seemed to work and, with a slightly modified ige-mac-integration, got nice mac-style menu bars etc. for my application. Unfortunately I'm travelling at the moment and don't have the mac with me and I'm a little hazy on the details but when I get back I'll try to write up my experience. Murray Campbell

Heinrich Apfelmus

4:53 a.m.

Jeremy O'Donoghue wrote:

...

- What everyone would *really* like is a less 'imperative' style of GUI programming. It's true that wxHaskell, GtkHS and so on basically let you do type safe C programming. This *does* need the uber type hackers and Haskell experts, but work in this direction has been equally stifled by the fact that the GUI bindings like wxHaskell tend not to get enough love to fix issues they are seeing.

The reactive-banana library is my attempt to work on that. http://apfelmus.nfshost.com/blog/2011/04/28-frp-banana-0-2.html Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com

Jeremy O'Donoghue

20 May 20 May

10:31 a.m.

On 19 May 2011 14:01, Heinrich Apfelmus wrote:

...

Conal Elliott wrote:

...
Last I heard, wx still had the problem of crashing its host the second time one opens a window (which is typical in ghci). And last I heard, Jeremy O'Donoghue (cc'd) was exploring solutions but had very little time to pursue them. - Conal

Last I remember, the latest problem is that ghci is unable to link libstdc++. But the crash problem is probably still there.

There are two separate problems: - ghci unable to link static libstdc++ (so doesn't work at all on Windows). Actually this should be fixed with ghc > 7.0.2, but I have not yet verified (in the process of doing so now), as ghc now ships with libstdc++ as a dll. - wxWidgets static destructors are not called when application terminates, so second app run crashes (all platforms) Jeremy

Jeremy O'Donoghue

10:25 a.m.

That's correct - I haven't yet got a stable solution for using ghci with wxHaskell - Jeremy On 18 May 2011 20:33, Conal Elliott wrote:

...

Last I heard, wx still had the problem of crashing its host the second time one opens a window (which is typical in ghci). And last I heard, Jeremy O'Donoghue (cc'd) was exploring solutions but had very little time to pursue them. - Conal

On Wed, May 18, 2011 at 11:42 AM, Tom Murphy wrote:

...
...
My conclusion was that GLFW-b (on hackage) is the best we have right now. I think we could do even better than the C libraries out there by writing the GLUT/GLFW/etc implementation purely in Haskell. We already have x11 and gtk bindings for the linux support. We have win32 api bindings for windows support. What we are lacking is good low level support for OSX GUI programming. Once we have that it's not too much of a stretch to use cabal to glue it together into a cross platform library. I believe that's the right way to go for the long term. Improving GLFW-b is a good short-term route.

Would it be possible to do it with wx? There would be a much larger potential developer pool, since it's cross-platform. (Not getting away from C libraries, but they're stable).

...
And just to say it one more time, I can use all the help I can get. There are a lot of yaks to be shaved. My hope is that if we all shave one yak then we'll quickly have the libraries we need to do some serious graphics hacking in Haskell. We already have many good libraries for it, we just need to improve and polish a few key libraries. The momentum is here and a few people have already jumped in. Time to get on board!

Count me as onboard; I'm just not sure which ship I'm on yet.

Tom

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

Sam Martin

19 May 19 May

4:15 a.m.

...

My conclusion was that GLFW-b (on hackage) is the best we have right now. I think we could do even better than the C libraries out there by writing the GLUT/GLFW/etc implementation purely in Haskell. We already have x11 and gtk bindings for the linux support. We have win32 api bindings for windows support. What we are lacking is good low level support for OSX GUI programming. Once we have that it's not too much of a stretch to use cabal to glue it together into a cross platform library. I believe that's the right way to go for the long term. Improving GLFW-b is a good short-term route.

I agree with your approach. Although getting a window on screen really isn't much code, so I'd vote for going straight to a Haskell replacement for GLUT et al.

...

And just to say it one more time, I can use all the help I can get.

I don't have much time, but if someone started a github project for a Haskell GLUT replacement I could probably chip in here and there. Ta, Sam

Heinrich Apfelmus

9 a.m.

Jason Dagit wrote:

...

As you point out we also need better libraries for creating the OpenGL context. I wrote up my searches on that front here: http://blog.codersbase.com/2011/03/picking-gui-library-to-use-with-opengl.ht...

My conclusion was that GLFW-b (on hackage) is the best we have right now. I think we could do even better than the C libraries out there by writing the GLUT/GLFW/etc implementation purely in Haskell.

Not sure about that. I have looked at the GLFW source code, it's the cleanest C code I have ever seen and definitely worth contributing to. The thing with established cross-platform GUI toolkits is that they embed a lot of wisdom about platform quirks (Cocoa is particularly annoying) that you would have to solve again. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com

KC

8:30 p.m.

Do GUIs or interactive graphics in Haskell work a lot better on Windows and/or various Linux distro's? On Tue, May 17, 2011 at 4:24 PM, Conal Elliott wrote:

...

I still haven't found any way to do GUIs or interactive graphics in Haskell on a Mac that isn't plagued one or more of the following serious problems:

* Incompatible with ghci, e.g., fails to make a window frame or kills the process the second time one opens a top-level window, * Goes through the X server, and so doesn't look or act like a Mac app, * Doesn't support OpenGL.

A year or two ago, I put my Haskell GUI & graphics work on hold while waiting & hoping for a functioning pathway to open. So far I haven't heard of one.

If anyone has found a solution, I'd love to hear!

- Conal

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

-- -- Regards, KC

5110

Age (days ago)

5118

Last active (days ago)

List overview

Download

42 comments

22 participants

participants (22)

Andrew Butterfield
Conal Elliott
Donn Cave
Eric Y. Kow
Erik Hesselink
Evan Laforge
Felipe Almeida Lessa
Gregory Crosswhite
Heinrich Apfelmus
Jason Dagit
Jeremy O'Donoghue
John Lask
Jurriën Stutterheim
KC
KQ
Manuel M T Chakravarty
Michael Snoyman
murray＠sonology.net
Sam Martin
Stephen Tetley
Tom Murphy
wren ng thornton