Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
Sven Panne wrote: 2013/9/27 Conal Elliott co...@conal.net: [...] Am I mistaken about the current status? I.e., is there a solution for Haskell GUI graphics programming that satisfies the properties I'm looking for (cross-platform, easily buildable, GHCi-friendly, and OpenGL-compatible)? [...] Time warp! ;-) Point your browser at the g...@haskell.org archives a decade ago... I think the consensus at that time was a bit disappointing: Either one could have something portable but hard to install and alien-looking, or something non-portable but easy to install and native-looking. The fundamental UI concepts on the various platforms differed so much that there was no hope for a grand unified pretty UI library, so those GUI efforts basically ended. I think the reasoning behind this hasn't changed recently, but I would love being proven wrong. Well, the advent of modern browsers has changed the first alternative to portable, easy to install and alien-looking. That's the niche I'm belaboring with threepenny-gui. Personally, I think that the easy to install criterion beats all the others -- it is hard to use a GUI library that you can't install. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
Sven Panne wrote: 2013/9/27 Heinrich Apfelmus apfel...@quantentunnel.de: Actually, I'm reading about WebGL right now, and it appears to me that it should be very easy to support in Threepenny. [...] I am not sure if WebGL is enough: WebGL is basically OpenGL ES 2.0, which is again basically OpenGL 2.0 plus some extensions. OpenGL itself is currently at 4.4, and the situation regarding the supported shading language versions is even worse. In a nutshell: WebGL = ancient OpenGL. If it's enough for your purposes, fine, but otherwise I guess a lot of people want something more recent. Fair enough. I have never really worked with OpenGL and its variants, so I wouldn't know. That said, from a cursory look, I get the impression that OpenGL ES 2.0 was the recent standard on mobile platforms. For instance, iOS 7 just recently introduced OpenGL ES 3.0 support. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
2013/9/27 Heinrich Apfelmus apfel...@quantentunnel.de: Actually, I'm reading about WebGL right now, and it appears to me that it should be very easy to support in Threepenny. [...] I am not sure if WebGL is enough: WebGL is basically OpenGL ES 2.0, which is again basically OpenGL 2.0 plus some extensions. OpenGL itself is currently at 4.4, and the situation regarding the supported shading language versions is even worse. In a nutshell: WebGL = ancient OpenGL. If it's enough for your purposes, fine, but otherwise I guess a lot of people want something more recent. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
2013/9/27 Conal Elliott co...@conal.net: [...] Am I mistaken about the current status? I.e., is there a solution for Haskell GUI graphics programming that satisfies the properties I'm looking for (cross-platform, easily buildable, GHCi-friendly, and OpenGL-compatible)? [...] Time warp! ;-) Point your browser at the g...@haskell.org archives a decade ago... I think the consensus at that time was a bit disappointing: Either one could have something portable but hard to install and alien-looking, or something non-portable but easy to install and native-looking. The fundamental UI concepts on the various platforms differed so much that there was no hope for a grand unified pretty UI library, so those GUI efforts basically ended. I think the reasoning behind this hasn't changed recently, but I would love being proven wrong. Cheers, S. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
I think you've misunderstood Robin's point. The problem is that each of these libraries is platform-specific. Writing an api on top of one is work enough, but writing a cross-platform api that binds to the appropriate platform-specific backend is a major undertaking. On Oct 4, 2013 7:12 PM, Alp Mestanogullari alpmes...@gmail.com wrote: If these said libraries let us write a good API on top, then perfect! The problem is to actually pick the ones fulfilling our needs I think, all the major candidatures have pretty serious drawbacks, AFAIK. On Sat, Oct 5, 2013 at 12:36 AM, Robin KAY komad...@gekkou.co.uk wrote: Dear Alp, Alp Mestanogullari wrote: [snip] I have been willing to have a nice GUI DSEL with good aesthetics for a while. I think the hardest part wouldn't be the API, but really what library we use underneath so that it's cross-platform and easy to install for everyone. But I would love for something like that to happen and am very interested in this. Herein lies, for my purposes, the downfall of attempts to build GUI tool-kits on top of a blank canvas. From the perspective of binding to the platform, getting the basic functionality of a cross-platform GLUT or SDL equivalent isn't terribly difficult. You can layer your own widget system on top but even if you don't care about native look and feel (and I don't particularly), there are still three big functionality hurdles in my mind to building serious applications:- i) Proper text rendering is more difficult than placing one glyph after another on a line. You need to bind to each platform's text rendering engine: Pango/others, Uniscribe, and Core Text. ii) Proper text input is more difficult than listening for key press and release events. You need to bind to the each platform's input method system: XIM/IBus/others, IMM, and NSTextInputClient. iii) Proper accessibility is just difficult. There are plenty of applications where that doesn't matter and there are lots of attractive things about a pure Haskell implementation with beautiful high-level API. However, from my perspective, there are also attractions to outsourcing as much of that work as possible to existing libraries on the other side of the FFI even though that seems to bring us down to lower-level. Regards, -- Robin KAY ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Alp Mestanogullari ___ 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
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
). I do not know the details of this, but it sounds like a pretty serious problem, and it used to work. Is whatever-it-is confirmed fixed in 7.8? Do we have a test that’ll trip if it breaks again? (I’m guessing that the latter might be hard.) Thanks Simon -Original Message- From: Haskell-Cafe [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Paul Liu Sent: 30 September 2013 07:18 To: Conal Elliott Cc: Haskell Cafe Subject: Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell Hi Conal, I wasn't able to make it to last Saturday's FARM track, but I think there was a good chance that Paul would have demonstrated his Euterpea music library, which includes a GUI interface (called MUI) written on top of GLFW. I wrote its initial implementation (around 2009?) with a monadic interface that let you wire together UI components with signals (I believe Dan later wrote an arrow interface, but I could be wrong). It was actually inspired by the ideas behind your Phooey UI library. It should be very easy to extract this part out as a standalone package if there is enough interest. The only issue with it (and all other UI libraries) is that it doesn't play nicely in GHCi. It used to work pretty well with GHC 7.2 and 7.4 on almost all platforms (Mac needs an extra hack), but GHC 7.6 broke Mac (and perhaps Windows too). GHC 7.8 supposedly should fix this problem. BTW, as also the author of the GLFW library on HackageDB, I've done barely minimal to keep this Haskell binding afloat. I'm actually leaning towards GLFW-b library, which is better maintained, and provides similar binding for GLFW C library but with a saner interface (no dependency on the OpenGL library, for example). If you don't need the two extra things that GLFW does (choice of either dynamic or static linking to GLFW C, and an embedded bitmap font), I suggest you try out GLFW-b if you are only looking for a think graphics layer with input+window+OpenGL. The only thing keeping GLFW-b from becoming a good foundation for a pure Haskell UI lib is IMHO the lack of a light-weight, cross-platform, and full-featured font rendering solution. I believe many other libraries (including Diagram) are having the same problem. On Thu, Sep 26, 2013 at 8:32 PM, Conal Elliott co...@conal.net wrote: I'm polling to see whether there are will and expertise to reboot graphics and GUIs work in Haskell. I miss working on functional graphics and GUIs in Haskell, as I've been blocked for several years (eight?) due to the absence of low-level foundation libraries having the following properties: * cross-platform, * easily buildable, * GHCi-friendly, and * OpenGL-compatible. The last several times I tried Gtk2hs, I was unable to compile it on my Mac. Years ago when I was able to compile, the GUIs looked and interacted like a Linux app, which made them awkward and upleasant to use. wxHaskell (whose API and visual appearance I prefered) has for years been incompatible with GHCi, in that the second time I open a top-level window, the host process (GHCi) dies abruptly. Since my GUI graphics programs are often one-liners, and I tend to experiment a lot, using a full compilation greatly thwarts my flow. For many years, I've thought that the situation would eventually improve, since I'm far from the only person who wants GUIs or graphics from Haskell. About three years ago, I built a modern replacement of my old Pan and V ___ ghc-devs mailing list ghc-d...@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Paul Liu -- Regards, Paul Liu ___ ghc-devs mailing list ghc-d...@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Paul Liu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Alp Mestanogullari ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
for that 3) I'm not aware of anyone reporting newly broken libs wrt GUI bindings when 7.6 rolled out. The only fix that's relevant to 7.8 is the dylinker bit, but that would have been a problem historically too. I believe a number of folks in #haskell-game have recently tested point one. (Though I should ask to double check) At the very least, I'm not aware of hearing of such a 7.6 specific ghci breakage before. On Tuesday, October 1, 2013, Simon Peyton-Jones wrote: Dear GHC devs See below (in red). I do not know the details of this, but it sounds like a pretty serious problem, and it used to work. Is whatever-it-is confirmed fixed in 7.8? Do we have a test that’ll trip if it breaks again? (I’m guessing that the latter might be hard.) Thanks Simon -Original Message- From: Haskell-Cafe [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Paul Liu Sent: 30 September 2013 07:18 To: Conal Elliott Cc: Haskell Cafe Subject: Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell Hi Conal, I wasn't able to make it to last Saturday's FARM track, but I think there was a good chance that Paul would have demonstrated his Euterpea music library, which includes a GUI interface (called MUI) written on top of GLFW. I wrote its initial implementation (around 2009?) with a monadic interface that let you wire together UI components with signals (I believe Dan later wrote an arrow interface, but I could be wrong). It was actually inspired by the ideas behind your Phooey UI library. It should be very easy to extract this part out as a standalone package if there is enough interest. The only issue with it (and all other UI libraries) is that it doesn't play nicely in GHCi. It used to work pretty well with GHC 7.2 and 7.4 on almost all platforms (Mac needs an extra hack), but GHC 7.6 broke Mac (and perhaps Windows too). GHC 7.8 supposedly should fix this problem. BTW, as also the author of the GLFW library on HackageDB, I've done barely minimal to keep this Haskell binding afloat. I'm actually leaning towards GLFW-b library, which is better maintained, and provides similar binding for GLFW C library but with a saner interface (no dependency on the OpenGL library, for example). If you don't need the two extra things that GLFW does (choice of either dynamic or static linking to GLFW C, and an embedded bitmap font), I suggest you try out GLFW-b if you are only looking for a think graphics layer with input+window+OpenGL. The only thing keeping GLFW-b from becoming a good foundation for a pure Haskell UI lib is IMHO the lack of a light-weight, cross-platform, and full-featured font rendering solution. I believe many other libraries (including Diagram) are having the same problem. On Thu, Sep 26, 2013 at 8:32 PM, Conal Elliott co...@conal.net wrote: I'm polling to see whether there are will and expertise to reboot graphics and GUIs work in Haskell. I miss working on functional graphics and GUIs in Haskell, as I've been blocked for several years (eight?) due to the absence of low-level foundation libraries having the following properties: * cross-platform, * easily buildable, * GHCi-friendly, and * OpenGL-compatible. The last several times I tried Gtk2hs, I was unable to compile it on my Mac. Years ago when I was able to compile, the GUIs looked and interacted like a Linux app, which made them awkward and upleasant to use. wxHaskell (whose API and visual appearance I prefered) has for years been incompatible with GHCi, in that the second time I open a top-level window, the host process (GHCi) dies abruptly. Since my GUI graphics programs are often one-liners, and I tend to experiment a lot, using a full compilation greatly thwarts my flow. For many years, I've thought that the situation would eventually improve, since I'm far from the only person who wants GUIs or graphics from Haskell. About three years ago, I built a modern replacement of my old Pan and V ___ ghc-devs mailing list ghc-d...@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
for GHC 7.2 (and previous versions) and OS X version before Lion, but it no longer works. So I'm not sure if it is OS X Lion, or GLFW, or GHC, or a combination of them that caused this problem. Regards, Paul Liu On Tue, Oct 1, 2013 at 7:04 AM, Carter Schonwald carter.schonw...@gmail.com wrote: Hey simon, the two issues that have recurrently bit ghci interaction with foreign GUI libs are 1) the ghci linker. This is fixed in head by now having ghci use the system linker 2) some GUI libs require thread local state, and ghci has a flag for that 3) I'm not aware of anyone reporting newly broken libs wrt GUI bindings when 7.6 rolled out. The only fix that's relevant to 7.8 is the dylinker bit, but that would have been a problem historically too. I believe a number of folks in #haskell-game have recently tested point one. (Though I should ask to double check) At the very least, I'm not aware of hearing of such a 7.6 specific ghci breakage before. On Tuesday, October 1, 2013, Simon Peyton-Jones wrote: Dear GHC devs See below (in red). I do not know the details of this, but it sounds like a pretty serious problem, and it used to work. Is whatever-it-is confirmed fixed in 7.8? Do we have a test that’ll trip if it breaks again? (I’m guessing that the latter might be hard.) Thanks Simon -Original Message- From: Haskell-Cafe [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Paul Liu Sent: 30 September 2013 07:18 To: Conal Elliott Cc: Haskell Cafe Subject: Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell Hi Conal, I wasn't able to make it to last Saturday's FARM track, but I think there was a good chance that Paul would have demonstrated his Euterpea music library, which includes a GUI interface (called MUI) written on top of GLFW. I wrote its initial implementation (around 2009?) with a monadic interface that let you wire together UI components with signals (I believe Dan later wrote an arrow interface, but I could be wrong). It was actually inspired by the ideas behind your Phooey UI library. It should be very easy to extract this part out as a standalone package if there is enough interest. The only issue with it (and all other UI libraries) is that it doesn't play nicely in GHCi. It used to work pretty well with GHC 7.2 and 7.4 on almost all platforms (Mac needs an extra hack), but GHC 7.6 broke Mac (and perhaps Windows too). GHC 7.8 supposedly should fix this problem. BTW, as also the author of the GLFW library on HackageDB, I've done barely minimal to keep this Haskell binding afloat. I'm actually leaning towards GLFW-b library, which is better maintained, and provides similar binding for GLFW C library but with a saner interface (no dependency on the OpenGL library, for example). If you don't need the two extra things that GLFW does (choice of either dynamic or static linking to GLFW C, and an embedded bitmap font), I suggest you try out GLFW-b if you are only looking for a think graphics layer with input+window+OpenGL. The only thing keeping GLFW-b from becoming a good foundation for a pure Haskell UI lib is IMHO the lack of a light-weight, cross-platform, and full-featured font rendering solution. I believe many other libraries (including Diagram) are having the same problem. On Thu, Sep 26, 2013 at 8:32 PM, Conal Elliott co...@conal.net wrote: I'm polling to see whether there are will and expertise to reboot graphics and GUIs work in Haskell. I miss working on functional graphics and GUIs in Haskell, as I've been blocked for several years (eight?) due to the absence of low-level foundation libraries having the following properties: * cross-platform, * easily buildable, * GHCi-friendly, and * OpenGL-compatible. The last several times I tried Gtk2hs, I was unable to compile it on my Mac. Years ago when I was able to compile, the GUIs looked and interacted like a Linux app, which made them awkward and upleasant to use. wxHaskell (whose API and visual appearance I prefered) has for years been incompatible with GHCi, in that the second time I open a top-level window, the host process (GHCi) dies abruptly. Since my GUI graphics programs
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
Dear Alp, Alp Mestanogullari wrote: [snip] I have been willing to have a nice GUI DSEL with good aesthetics for a while. I think the hardest part wouldn't be the API, but really what library we use underneath so that it's cross-platform and easy to install for everyone. But I would love for something like that to happen and am very interested in this. Herein lies, for my purposes, the downfall of attempts to build GUI tool-kits on top of a blank canvas. From the perspective of binding to the platform, getting the basic functionality of a cross-platform GLUT or SDL equivalent isn't terribly difficult. You can layer your own widget system on top but even if you don't care about native look and feel (and I don't particularly), there are still three big functionality hurdles in my mind to building serious applications:- i) Proper text rendering is more difficult than placing one glyph after another on a line. You need to bind to each platform's text rendering engine: Pango/others, Uniscribe, and Core Text. ii) Proper text input is more difficult than listening for key press and release events. You need to bind to the each platform's input method system: XIM/IBus/others, IMM, and NSTextInputClient. iii) Proper accessibility is just difficult. There are plenty of applications where that doesn't matter and there are lots of attractive things about a pure Haskell implementation with beautiful high-level API. However, from my perspective, there are also attractions to outsourcing as much of that work as possible to existing libraries on the other side of the FFI even though that seems to bring us down to lower-level. Regards, -- Robin KAY ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
If these said libraries let us write a good API on top, then perfect! The problem is to actually pick the ones fulfilling our needs I think, all the major candidatures have pretty serious drawbacks, AFAIK. On Sat, Oct 5, 2013 at 12:36 AM, Robin KAY komad...@gekkou.co.uk wrote: Dear Alp, Alp Mestanogullari wrote: [snip] I have been willing to have a nice GUI DSEL with good aesthetics for a while. I think the hardest part wouldn't be the API, but really what library we use underneath so that it's cross-platform and easy to install for everyone. But I would love for something like that to happen and am very interested in this. Herein lies, for my purposes, the downfall of attempts to build GUI tool-kits on top of a blank canvas. From the perspective of binding to the platform, getting the basic functionality of a cross-platform GLUT or SDL equivalent isn't terribly difficult. You can layer your own widget system on top but even if you don't care about native look and feel (and I don't particularly), there are still three big functionality hurdles in my mind to building serious applications:- i) Proper text rendering is more difficult than placing one glyph after another on a line. You need to bind to each platform's text rendering engine: Pango/others, Uniscribe, and Core Text. ii) Proper text input is more difficult than listening for key press and release events. You need to bind to the each platform's input method system: XIM/IBus/others, IMM, and NSTextInputClient. iii) Proper accessibility is just difficult. There are plenty of applications where that doesn't matter and there are lots of attractive things about a pure Haskell implementation with beautiful high-level API. However, from my perspective, there are also attractions to outsourcing as much of that work as possible to existing libraries on the other side of the FFI even though that seems to bring us down to lower-level. Regards, -- Robin KAY __**_ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://www.haskell.org/mailman/listinfo/haskell-cafe -- Alp Mestanogullari ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
On Wed, 02 Oct 2013 12:24:25 +0200, Atze Dijkstra a...@uu.nl wrote: Hi, as for wxHaskell, it is currently maintained at https://github.com/wxHaskell/wxHaskell, compilable with wxWidgets 2.9.5 and GHC 7.6. Work is underway to fix various bugs introduced over time by changes in wxWidgets, but we (i.e. https://github.com/wxHaskell?tab=members) hope to release announce in not too much time. Not all members are publicly visible at the moment; the members must login and change visibility at this page. Regards, Henk-Jan van Tuyl -- Folding@home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
Thanks. I've just built GHC HEAD on Mac OS X Lion, and tested by installing libraries with --enable-shared and loading a GLFW program into GHCi. Using ghci -fno-ghci-sandbox, everything works great including closing and restarting GL window multiple times. Can't wait for the official release of GHC 7.8! On Tue, Oct 1, 2013 at 12:09 PM, Carter Schonwald carter.schonw...@gmail.com wrote: thats the linker bug. the glfw stuff has been tested on ghc HEAD / 7.7 by folks on #haskell-game in recent memory. GHCI + foreign libs should work fine now (modulo thread local storage related thing). the historical element doesn't matter any more. To the best of my knowledge, all such issues should be gone. Anyone who cares about making sure GHCI+ gui libs play nice, PLEASE test with HEAD. the better this issue is properly tested (which i believe it has been), the more we can actually prevent it from happening. This requires people to test with HEAD GHCi now, rather than doing archaeology. anyone who cares, please play with GHCI in HEAD. If your lib doesn't work with ghci, please report a bug. It would be a new bug because it wont' be the previous reasons it hasnt' worked. tl;dr to the best of my knowledge this issue is resolved in HEAD. Test HEAD. Help us make sure it stays resolved by testing HEAD. thanks -Carter On Tue, Oct 1, 2013 at 1:20 PM, Paul Liu nine...@gmail.com wrote: I reported a problem with statically linked GLFW library on Mac OS X Lion in this thread: http://www.haskell.org/pipermail/haskell-cafe/2012-January/097355.html I do not know why this is broken on Mac OS X Lion, but not on Linux or Windows. There was an EnableGUI hack for GHC 7.2 (and previous versions) and OS X version before Lion, but it no longer works. So I'm not sure if it is OS X Lion, or GLFW, or GHC, or a combination of them that caused this problem. Regards, Paul Liu On Tue, Oct 1, 2013 at 7:04 AM, Carter Schonwald carter.schonw...@gmail.com wrote: Hey simon, the two issues that have recurrently bit ghci interaction with foreign GUI libs are 1) the ghci linker. This is fixed in head by now having ghci use the system linker 2) some GUI libs require thread local state, and ghci has a flag for that 3) I'm not aware of anyone reporting newly broken libs wrt GUI bindings when 7.6 rolled out. The only fix that's relevant to 7.8 is the dylinker bit, but that would have been a problem historically too. I believe a number of folks in #haskell-game have recently tested point one. (Though I should ask to double check) At the very least, I'm not aware of hearing of such a 7.6 specific ghci breakage before. On Tuesday, October 1, 2013, Simon Peyton-Jones wrote: Dear GHC devs See below (in red). I do not know the details of this, but it sounds like a pretty serious problem, and it used to work. Is whatever-it-is confirmed fixed in 7.8? Do we have a test that’ll trip if it breaks again? (I’m guessing that the latter might be hard.) Thanks Simon -Original Message- From: Haskell-Cafe [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Paul Liu Sent: 30 September 2013 07:18 To: Conal Elliott Cc: Haskell Cafe Subject: Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell Hi Conal, I wasn't able to make it to last Saturday's FARM track, but I think there was a good chance that Paul would have demonstrated his Euterpea music library, which includes a GUI interface (called MUI) written on top of GLFW. I wrote its initial implementation (around 2009?) with a monadic interface that let you wire together UI components with signals (I believe Dan later wrote an arrow interface, but I could be wrong). It was actually inspired by the ideas behind your Phooey UI library. It should be very easy to extract this part out as a standalone package if there is enough interest. The only issue with it (and all other UI libraries) is that it doesn't play nicely in GHCi. It used to work pretty well with GHC 7.2 and 7.4 on almost all platforms (Mac needs an extra hack), but GHC 7.6 broke Mac (and perhaps Windows too). GHC 7.8 supposedly should fix this problem. BTW, as also the author of the GLFW library on HackageDB, I've done barely minimal to keep this Haskell binding afloat. I'm actually leaning towards GLFW-b library, which is better maintained, and provides similar binding for GLFW C library but with a saner interface (no dependency on the OpenGL library, for example). If you don't need the two extra things that GLFW does (choice of either dynamic or static linking to GLFW C, and an embedded bitmap font), I suggest you try out GLFW-b if you are only looking for a think graphics layer with input+window+OpenGL. The only thing keeping GLFW-b from becoming a good
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
Yay! Thanks Paul! It's always good to have more folks confirm the problems are solved than not! Another cool direction 7.8 will allow is using the various llvm ffi bindings from ghci! On Wednesday, October 2, 2013, Paul Liu wrote: Thanks. I've just built GHC HEAD on Mac OS X Lion, and tested by installing libraries with --enable-shared and loading a GLFW program into GHCi. Using ghci -fno-ghci-sandbox, everything works great including closing and restarting GL window multiple times. Can't wait for the official release of GHC 7.8! On Tue, Oct 1, 2013 at 12:09 PM, Carter Schonwald carter.schonw...@gmail.com wrote: thats the linker bug. the glfw stuff has been tested on ghc HEAD / 7.7 by folks on #haskell-game in recent memory. GHCI + foreign libs should work fine now (modulo thread local storage related thing). the historical element doesn't matter any more. To the best of my knowledge, all such issues should be gone. Anyone who cares about making sure GHCI+ gui libs play nice, PLEASE test with HEAD. the better this issue is properly tested (which i believe it has been), the more we can actually prevent it from happening. This requires people to test with HEAD GHCi now, rather than doing archaeology. anyone who cares, please play with GHCI in HEAD. If your lib doesn't work with ghci, please report a bug. It would be a new bug because it wont' be the previous reasons it hasnt' worked. tl;dr to the best of my knowledge this issue is resolved in HEAD. Test HEAD. Help us make sure it stays resolved by testing HEAD. thanks -Carter On Tue, Oct 1, 2013 at 1:20 PM, Paul Liu nine...@gmail.com wrote: I reported a problem with statically linked GLFW library on Mac OS X Lion in this thread: http://www.haskell.org/pipermail/haskell-cafe/2012-January/097355.html I do not know why this is broken on Mac OS X Lion, but not on Linux or Windows. There was an EnableGUI hack for GHC 7.2 (and previous versions) and OS X version before Lion, but it no longer works. So I'm not sure if it is OS X Lion, or GLFW, or GHC, or a combination of them that caused this problem. Regards, Paul Liu On Tue, Oct 1, 2013 at 7:04 AM, Carter Schonwald carter.schonw...@gmail.com wrote: Hey simon, the two issues that have recurrently bit ghci interaction with foreign GUI libs are 1) the ghci linker. This is fixed in head by now having ghci use the system linker 2) some GUI libs require thread local state, and ghci has a flag for that 3) I'm not aware of anyone reporting newly broken libs wrt GUI bindings when 7.6 rolled out. The only fix that's relevant to 7.8 is the dylinker bit, but that would have been a problem historically too. I believe a number of folks in #haskell-game have recently tested point one. (Though I should ask to double check) At the very least, I'm not aware of hearing of such a 7.6 specific ghci breakage before. On Tuesday, October 1, 2013, Simon Peyton-Jones wrote: Dear GHC devs See below (in red). I do not know the details of this, but it sounds like a pretty serious problem, and it used to work. Is whatever-it-is confirmed fixed in 7.8? Do we have a test that’ll trip if it breaks again? (I’m guessing that the latter might be hard.) Thanks Simon -Original Message- From: Haskell-Cafe [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Paul Liu Sent: 30 September 2013 07:18 To: Conal Elliott Cc: Haskell Cafe Subject: Re: [Haskell-ca-- Regards, Paul Liu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
Hi, as for wxHaskell, it is currently maintained at https://github.com/wxHaskell/wxHaskell, compilable with wxWidgets 2.9.5 and GHC 7.6. Work is underway to fix various bugs introduced over time by changes in wxWidgets, but we (i.e. https://github.com/wxHaskell?tab=members) hope to release announce in not too much time. cheers, Atze On 30 Sep, 2013, at 20:32 , Conal Elliott co...@conal.net wrote: Hi Conrad, Great. The challenge is not specific to Pan, Vertigo, etc. If we can get some low-level GUI platform working with the characteristics I listed, I can resurrect and my high-level libraries accordingly. Any GUI program containing at least one OpenGL window would probably get us most of the way there (again, noting the properties I listed). -- Conal On Fri, Sep 27, 2013 at 1:40 AM, Conrad Parker con...@metadecks.org wrote: Hi Conal! Yes. I'd be very interested to help get Pan and Vertigo working. Do you have a repo somewhere? Conrad. On 27 September 2013 13:32, Conal Elliott co...@conal.net wrote: I'm polling to see whether there are will and expertise to reboot graphics and GUIs work in Haskell. I miss working on functional graphics and GUIs in Haskell, as I've been blocked for several years (eight?) due to the absence of low-level foundation libraries having the following properties: * cross-platform, * easily buildable, * GHCi-friendly, and * OpenGL-compatible. The last several times I tried Gtk2hs, I was unable to compile it on my Mac. Years ago when I was able to compile, the GUIs looked and interacted like a Linux app, which made them awkward and upleasant to use. wxHaskell (whose API and visual appearance I prefered) has for years been incompatible with GHCi, in that the second time I open a top-level window, the host process (GHCi) dies abruptly. Since my GUI graphics programs are often one-liners, and I tend to experiment a lot, using a full compilation greatly thwarts my flow. For many years, I've thought that the situation would eventually improve, since I'm far from the only person who wants GUIs or graphics from Haskell. About three years ago, I built a modern replacement of my old Pan and Vertigo systems (optimized high-level functional graphics in 2D and 3D), generating screamingly fast GPU rendering code. I'd love to share it with the community, but I'm unable to use it even myself. Two questions: * Am I mistaken about the current status? I.e., is there a solution for Haskell GUI graphics programming that satisfies the properties I'm looking for (cross-platform, easily buildable, GHCi-friendly, and OpenGL-compatible)? * Are there people willing and able to fix this situation? My own contributions would be to test and to share high-level composable and efficient GUI and graphics libraries on top of a working foundation. Looking forward to replies. Thanks, -- Conal ___ 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 - Atze - Atze Dijkstra, Department of Information and Computing Sciences. /|\ Utrecht University, PO Box 80089, 3508 TB Utrecht, Netherlands. / | \ Tel.: +31-30-2534118/1454 | WWW : http://www.cs.uu.nl/~atze . /--| \ Fax : +31-30-2513971 | Email: a...@uu.nl ... / |___\ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
Hi, The best low-level foundation libraries that I know of are the Enlightenment Foundation Libraries (EFL) [1,2]. They are cross-platform : they support many backends (X11, OpenGL, framebuffer...) and are used on desktops and mobile devices (even to provide games on the French Free ISP box). It seems that they also work on exotic platforms such as Windows and Mac OS. They are fully written in C, hence are easy to build and to use from Haskell. Evas [3] is a stateful canvas onto which shapes and texts can be drawn. It supports OpenGL regions [4]. Ecore [5] is used to manage windows, timers, etc. especially with Ecore_Evas [6]. Edje allows you to clearly separate UI and the rest of the code. The same thing has been integrated into Qt with QML (and was present in Delphi decades ago ;)). It makes it easy to create animated UI, etc. Finally, Elementary is a standard widget toolkit based on Edje, Evas and Ecore. The good news is that I have been working on an Haskell binding for the EFL [7]. The bad news is that it is not complete. Evas, Ecore and Ecore_Evas are partially done but need more polishing and testing. This simple example here [8] works well in GHCI (even better than when the program is compiled because I haven't yet figured out why the text is not displayed in this latter case...). I do not plan to write bindings for Edje and Elementary as I would prefer an Haskell DSL to replace Edje and a widget toolkit on top of it (another project seems to provide some bindings for Elementary [9]). If you want to use the EFL as a working foundation, I can try to work a little bit more on the binding. Cheers Sylvain [1] http://en.wikipedia.org/wiki/Enlightenment_Foundation_Libraries [2] http://www.enlightenment.org/p.php?p=aboutl=en [3] http://docs.enlightenment.org/auto/evas [4] http://docs.enlightenment.org/auto/evas/group__Evas__GL.html [5] http://docs.enlightenment.org/auto/ecore/ [6] http://docs.enlightenment.org/auto/ecore/group__Ecore__Evas__Group.html [7] https://github.com/hsyl20/graphics-efl [8] https://github.com/hsyl20/graphics-efl/blob/master/examples/Simple.hs [9] https://bitbucket.org/arrowdodger/efl-haskell Le 27/09/2013 05:32, Conal Elliott a écrit : I'm polling to see whether there are will and expertise to reboot graphics and GUIs work in Haskell. I miss working on functional graphics and GUIs in Haskell, as I've been blocked for several years (eight?) due to the absence of low-level foundation libraries having the following properties: * cross-platform, * easily buildable, * GHCi-friendly, and * OpenGL-compatible. The last several times I tried Gtk2hs, I was unable to compile it on my Mac. Years ago when I was able to compile, the GUIs looked and interacted like a Linux app, which made them awkward and upleasant to use. wxHaskell (whose API and visual appearance I prefered) has for years been incompatible with GHCi, in that the second time I open a top-level window, the host process (GHCi) dies abruptly. Since my GUI graphics programs are often one-liners, and I tend to experiment a lot, using a full compilation greatly thwarts my flow. For many years, I've thought that the situation would eventually improve, since I'm far from the only person who wants GUIs or graphics from Haskell. About three years ago, I built a modern replacement of my old Pan and Vertigo systems (optimized high-level functional graphics in 2D and 3D), generating screamingly fast GPU rendering code. I'd love to share it with the community, but I'm unable to use it even myself. Two questions: * Am I mistaken about the current status? I.e., is there a solution for Haskell GUI graphics programming that satisfies the properties I'm looking for (cross-platform, easily buildable, GHCi-friendly, and OpenGL-compatible)? * Are there people willing and able to fix this situation? My own contributions would be to test and to share high-level composable and efficient GUI and graphics libraries on top of a working foundation. Looking forward to replies. Thanks, -- Conal ___ 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
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
Hi Atze. I'm glad to hear that some work is going into wxHaskell. Do you know about the issue that arose roughly 7-8 years ago that prevented opening more than one top-level window per process? It had to do with a change to initialization techniques, and made wxHaskell no longer useful with GHCi. -- Conal On Wed, Oct 2, 2013 at 3:24 AM, Atze Dijkstra a...@uu.nl wrote: Hi, as for wxHaskell, it is currently maintained at https://github.com/wxHaskell/wxHaskell, compilable with wxWidgets 2.9.5 and GHC 7.6. Work is underway to fix various bugs introduced over time by changes in wxWidgets, but we (i.e. https://github.com/wxHaskell?tab=members) hope to release announce in not too much time. cheers, Atze On 30 Sep, 2013, at 20:32 , Conal Elliott co...@conal.net wrote: Hi Conrad, Great. The challenge is not specific to Pan, Vertigo, etc. If we can get some low-level GUI platform working with the characteristics I listed, I can resurrect and my high-level libraries accordingly. Any GUI program containing at least one OpenGL window would probably get us most of the way there (again, noting the properties I listed). -- Conal On Fri, Sep 27, 2013 at 1:40 AM, Conrad Parker con...@metadecks.org wrote: Hi Conal! Yes. I'd be very interested to help get Pan and Vertigo working. Do you have a repo somewhere? Conrad. On 27 September 2013 13:32, Conal Elliott co...@conal.net wrote: I'm polling to see whether there are will and expertise to reboot graphics and GUIs work in Haskell. I miss working on functional graphics and GUIs in Haskell, as I've been blocked for several years (eight?) due to the absence of low-level foundation libraries having the following properties: * cross-platform, * easily buildable, * GHCi-friendly, and * OpenGL-compatible. The last several times I tried Gtk2hs, I was unable to compile it on my Mac. Years ago when I was able to compile, the GUIs looked and interacted like a Linux app, which made them awkward and upleasant to use. wxHaskell (whose API and visual appearance I prefered) has for years been incompatible with GHCi, in that the second time I open a top-level window, the host process (GHCi) dies abruptly. Since my GUI graphics programs are often one-liners, and I tend to experiment a lot, using a full compilation greatly thwarts my flow. For many years, I've thought that the situation would eventually improve, since I'm far from the only person who wants GUIs or graphics from Haskell. About three years ago, I built a modern replacement of my old Pan and Vertigo systems (optimized high-level functional graphics in 2D and 3D), generating screamingly fast GPU rendering code. I'd love to share it with the community, but I'm unable to use it even myself. Two questions: * Am I mistaken about the current status? I.e., is there a solution for Haskell GUI graphics programming that satisfies the properties I'm looking for (cross-platform, easily buildable, GHCi-friendly, and OpenGL-compatible)? * Are there people willing and able to fix this situation? My own contributions would be to test and to share high-level composable and efficient GUI and graphics libraries on top of a working foundation. Looking forward to replies. Thanks, -- Conal ___ 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 - Atze - Atze Dijkstra, Department of Information and Computing Sciences. /|\ Utrecht University, PO Box 80089, 3508 TB Utrecht, Netherlands. / | \ Tel.: +31-30-2534118/1454 | WWW : http://www.cs.uu.nl/~atze . /--| \ Fax : +31-30-2513971 | Email: a...@uu.nl ... / |___\ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
Hi Paul. Is there a way to use GLFW with GUI elements other than OpenGL display windows, e.g., text boxes and sliders? -- Conal On Tue, Oct 1, 2013 at 11:23 PM, Paul Liu nine...@gmail.com wrote: Thanks. I've just built GHC HEAD on Mac OS X Lion, and tested by installing libraries with --enable-shared and loading a GLFW program into GHCi. Using ghci -fno-ghci-sandbox, everything works great including closing and restarting GL window multiple times. Can't wait for the official release of GHC 7.8! On Tue, Oct 1, 2013 at 12:09 PM, Carter Schonwald carter.schonw...@gmail.com wrote: thats the linker bug. the glfw stuff has been tested on ghc HEAD / 7.7 by folks on #haskell-game in recent memory. GHCI + foreign libs should work fine now (modulo thread local storage related thing). the historical element doesn't matter any more. To the best of my knowledge, all such issues should be gone. Anyone who cares about making sure GHCI+ gui libs play nice, PLEASE test with HEAD. the better this issue is properly tested (which i believe it has been), the more we can actually prevent it from happening. This requires people to test with HEAD GHCi now, rather than doing archaeology. anyone who cares, please play with GHCI in HEAD. If your lib doesn't work with ghci, please report a bug. It would be a new bug because it wont' be the previous reasons it hasnt' worked. tl;dr to the best of my knowledge this issue is resolved in HEAD. Test HEAD. Help us make sure it stays resolved by testing HEAD. thanks -Carter On Tue, Oct 1, 2013 at 1:20 PM, Paul Liu nine...@gmail.com wrote: I reported a problem with statically linked GLFW library on Mac OS X Lion in this thread: http://www.haskell.org/pipermail/haskell-cafe/2012-January/097355.html I do not know why this is broken on Mac OS X Lion, but not on Linux or Windows. There was an EnableGUI hack for GHC 7.2 (and previous versions) and OS X version before Lion, but it no longer works. So I'm not sure if it is OS X Lion, or GLFW, or GHC, or a combination of them that caused this problem. Regards, Paul Liu On Tue, Oct 1, 2013 at 7:04 AM, Carter Schonwald carter.schonw...@gmail.com wrote: Hey simon, the two issues that have recurrently bit ghci interaction with foreign GUI libs are 1) the ghci linker. This is fixed in head by now having ghci use the system linker 2) some GUI libs require thread local state, and ghci has a flag for that 3) I'm not aware of anyone reporting newly broken libs wrt GUI bindings when 7.6 rolled out. The only fix that's relevant to 7.8 is the dylinker bit, but that would have been a problem historically too. I believe a number of folks in #haskell-game have recently tested point one. (Though I should ask to double check) At the very least, I'm not aware of hearing of such a 7.6 specific ghci breakage before. On Tuesday, October 1, 2013, Simon Peyton-Jones wrote: Dear GHC devs See below (in red). I do not know the details of this, but it sounds like a pretty serious problem, and it used to work. Is whatever-it-is confirmed fixed in 7.8? Do we have a test that’ll trip if it breaks again? (I’m guessing that the latter might be hard.) Thanks Simon -Original Message- From: Haskell-Cafe [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Paul Liu Sent: 30 September 2013 07:18 To: Conal Elliott Cc: Haskell Cafe Subject: Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell Hi Conal, I wasn't able to make it to last Saturday's FARM track, but I think there was a good chance that Paul would have demonstrated his Euterpea music library, which includes a GUI interface (called MUI) written on top of GLFW. I wrote its initial implementation (around 2009?) with a monadic interface that let you wire together UI components with signals (I believe Dan later wrote an arrow interface, but I could be wrong). It was actually inspired by the ideas behind your Phooey UI library. It should be very easy to extract this part out as a standalone package if there is enough interest. The only issue with it (and all other UI libraries) is that it doesn't play nicely in GHCi. It used to work pretty well with GHC 7.2 and 7.4 on almost all platforms (Mac needs an extra hack), but GHC 7.6 broke Mac (and perhaps Windows too). GHC 7.8 supposedly should fix this problem. BTW, as also the author of the GLFW library on HackageDB, I've done barely minimal to keep this Haskell binding afloat. I'm actually leaning towards GLFW-b library, which is better maintained, and provides similar binding for GLFW C library but with a saner interface
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
Great to hear that we're getting some payoff for the switch to dynamic linking in GHCi. Thanks for testing! Cheers Simon On 02/10/2013 07:23, Paul Liu wrote: Thanks. I've just built GHC HEAD on Mac OS X Lion, and tested by installing libraries with --enable-shared and loading a GLFW program into GHCi. Using ghci -fno-ghci-sandbox, everything works great including closing and restarting GL window multiple times. Can't wait for the official release of GHC 7.8! On Tue, Oct 1, 2013 at 12:09 PM, Carter Schonwald carter.schonw...@gmail.com wrote: thats the linker bug. the glfw stuff has been tested on ghc HEAD / 7.7 by folks on #haskell-game in recent memory. GHCI + foreign libs should work fine now (modulo thread local storage related thing). the historical element doesn't matter any more. To the best of my knowledge, all such issues should be gone. Anyone who cares about making sure GHCI+ gui libs play nice, PLEASE test with HEAD. the better this issue is properly tested (which i believe it has been), the more we can actually prevent it from happening. This requires people to test with HEAD GHCi now, rather than doing archaeology. anyone who cares, please play with GHCI in HEAD. If your lib doesn't work with ghci, please report a bug. It would be a new bug because it wont' be the previous reasons it hasnt' worked. tl;dr to the best of my knowledge this issue is resolved in HEAD. Test HEAD. Help us make sure it stays resolved by testing HEAD. thanks -Carter On Tue, Oct 1, 2013 at 1:20 PM, Paul Liu nine...@gmail.com wrote: I reported a problem with statically linked GLFW library on Mac OS X Lion in this thread: http://www.haskell.org/pipermail/haskell-cafe/2012-January/097355.html I do not know why this is broken on Mac OS X Lion, but not on Linux or Windows. There was an EnableGUI hack for GHC 7.2 (and previous versions) and OS X version before Lion, but it no longer works. So I'm not sure if it is OS X Lion, or GLFW, or GHC, or a combination of them that caused this problem. Regards, Paul Liu On Tue, Oct 1, 2013 at 7:04 AM, Carter Schonwald carter.schonw...@gmail.com wrote: Hey simon, the two issues that have recurrently bit ghci interaction with foreign GUI libs are 1) the ghci linker. This is fixed in head by now having ghci use the system linker 2) some GUI libs require thread local state, and ghci has a flag for that 3) I'm not aware of anyone reporting newly broken libs wrt GUI bindings when 7.6 rolled out. The only fix that's relevant to 7.8 is the dylinker bit, but that would have been a problem historically too. I believe a number of folks in #haskell-game have recently tested point one. (Though I should ask to double check) At the very least, I'm not aware of hearing of such a 7.6 specific ghci breakage before. On Tuesday, October 1, 2013, Simon Peyton-Jones wrote: Dear GHC devs See below (in red). I do not know the details of this, but it sounds like a pretty serious problem, and it used to work. Is whatever-it-is confirmed fixed in 7.8? Do we have a test that’ll trip if it breaks again? (I’m guessing that the latter might be hard.) Thanks Simon -Original Message- From: Haskell-Cafe [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Paul Liu Sent: 30 September 2013 07:18 To: Conal Elliott Cc: Haskell Cafe Subject: Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell Hi Conal, I wasn't able to make it to last Saturday's FARM track, but I think there was a good chance that Paul would have demonstrated his Euterpea music library, which includes a GUI interface (called MUI) written on top of GLFW. I wrote its initial implementation (around 2009?) with a monadic interface that let you wire together UI components with signals (I believe Dan later wrote an arrow interface, but I could be wrong). It was actually inspired by the ideas behind your Phooey UI library. It should be very easy to extract this part out as a standalone package if there is enough interest. The only issue with it (and all other UI libraries) is that it doesn't play nicely in GHCi. It used to work pretty well with GHC 7.2 and 7.4 on almost all platforms (Mac needs an extra hack), but GHC 7.6 broke Mac (and perhaps Windows too). GHC 7.8 supposedly should fix this problem. BTW, as also the author of the GLFW library on HackageDB, I've done barely minimal to keep this Haskell binding afloat. I'm actually leaning towards GLFW-b library, which is better maintained, and provides similar binding for GLFW C library but with a saner interface (no dependency on the OpenGL library, for example). If you don't need the two extra things that GLFW does (choice of either dynamic or static linking to GLFW C, and an embedded bitmap font), I suggest you try out GLFW-b if you are only looking for a think graphics layer with input+window+OpenGL. The only thing keeping GLFW-b from becoming a good foundation for a pure Haskell UI lib
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
No. GLFW does not give you any UI elements, just basic windowing and input handling. Euterpea has a UI layer on top of GLFW that provides text boxes and sliders, etc, entirely written in Haskell. On Wed, Oct 2, 2013 at 8:40 AM, Conal Elliott co...@conal.net wrote: Hi Paul. Is there a way to use GLFW with GUI elements other than OpenGL display windows, e.g., text boxes and sliders? -- Conal On Tue, Oct 1, 2013 at 11:23 PM, Paul Liu nine...@gmail.com wrote: Thanks. I've just built GHC HEAD on Mac OS X Lion, and tested by installing libraries with --enable-shared and loading a GLFW program into GHCi. Using ghci -fno-ghci-sandbox, everything works great including closing and restarting GL window multiple times. Can't wait for the official release of GHC 7.8! On Tue, Oct 1, 2013 at 12:09 PM, Carter Schonwald carter.schonw...@gmail.com wrote: thats the linker bug. the glfw stuff has been tested on ghc HEAD / 7.7 by folks on #haskell-game in recent memory. GHCI + foreign libs should work fine now (modulo thread local storage related thing). the historical element doesn't matter any more. To the best of my knowledge, all such issues should be gone. Anyone who cares about making sure GHCI+ gui libs play nice, PLEASE test with HEAD. the better this issue is properly tested (which i believe it has been), the more we can actually prevent it from happening. This requires people to test with HEAD GHCi now, rather than doing archaeology. anyone who cares, please play with GHCI in HEAD. If your lib doesn't work with ghci, please report a bug. It would be a new bug because it wont' be the previous reasons it hasnt' worked. tl;dr to the best of my knowledge this issue is resolved in HEAD. Test HEAD. Help us make sure it stays resolved by testing HEAD. thanks -Carter On Tue, Oct 1, 2013 at 1:20 PM, Paul Liu nine...@gmail.com wrote: I reported a problem with statically linked GLFW library on Mac OS X Lion in this thread: http://www.haskell.org/pipermail/haskell-cafe/2012-January/097355.html I do not know why this is broken on Mac OS X Lion, but not on Linux or Windows. There was an EnableGUI hack for GHC 7.2 (and previous versions) and OS X version before Lion, but it no longer works. So I'm not sure if it is OS X Lion, or GLFW, or GHC, or a combination of them that caused this problem. Regards, Paul Liu On Tue, Oct 1, 2013 at 7:04 AM, Carter Schonwald carter.schonw...@gmail.com wrote: Hey simon, the two issues that have recurrently bit ghci interaction with foreign GUI libs are 1) the ghci linker. This is fixed in head by now having ghci use the system linker 2) some GUI libs require thread local state, and ghci has a flag for that 3) I'm not aware of anyone reporting newly broken libs wrt GUI bindings when 7.6 rolled out. The only fix that's relevant to 7.8 is the dylinker bit, but that would have been a problem historically too. I believe a number of folks in #haskell-game have recently tested point one. (Though I should ask to double check) At the very least, I'm not aware of hearing of such a 7.6 specific ghci breakage before. On Tuesday, October 1, 2013, Simon Peyton-Jones wrote: Dear GHC devs See below (in red). I do not know the details of this, but it sounds like a pretty serious problem, and it used to work. Is whatever-it-is confirmed fixed in 7.8? Do we have a test that’ll trip if it breaks again? (I’m guessing that the latter might be hard.) Thanks Simon -Original Message- From: Haskell-Cafe [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Paul Liu Sent: 30 September 2013 07:18 To: Conal Elliott Cc: Haskell Cafe Subject: Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell Hi Conal, I wasn't able to make it to last Saturday's FARM track, but I think there was a good chance that Paul would have demonstrated his Euterpea music library, which includes a GUI interface (called MUI) written on top of GLFW. I wrote its initial implementation (around 2009?) with a monadic interface that let you wire together UI components with signals (I believe Dan later wrote an arrow interface, but I could be wrong). It was actually inspired by the ideas behind your Phooey UI library. It should be very easy to extract this part out as a standalone package if there is enough interest. The only issue with it (and all other UI libraries) is that it doesn't play nicely in GHCi. It used to work pretty well with GHC 7.2 and 7.4 on almost all platforms (Mac needs an extra hack), but GHC 7.6 broke Mac (and perhaps Windows too). GHC 7.8 supposedly should fix this problem
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
Interesting. How are the aesthetics? Can you point me to screen shots? It'd be a lot of work, but one cool project would be to create *beautiful* GUI elements using OpenGL programmable shaders. Given the speed of GPUs, we could afford to put a lot into visual details. A complementary project is designing a semantically precise and elegant (denotative/genuinely functional to use Peter Landin's terms) GUI DSEL that would be simpler and more powerful than the conventional OO-inspired libraries we have so much trouble getting to work in Haskell. I've thought about this sort of thing on and off for a very long time and would be happy to be involved if others are interested also. Together, these two efforts would yield an approach to GUIs that is beautiful inside and out. -- Conal On Wed, Oct 2, 2013 at 1:21 PM, Paul Liu nine...@gmail.com wrote: No. GLFW does not give you any UI elements, just basic windowing and input handling. Euterpea has a UI layer on top of GLFW that provides text boxes and sliders, etc, entirely written in Haskell. On Wed, Oct 2, 2013 at 8:40 AM, Conal Elliott co...@conal.net wrote: Hi Paul. Is there a way to use GLFW with GUI elements other than OpenGL display windows, e.g., text boxes and sliders? -- Conal On Tue, Oct 1, 2013 at 11:23 PM, Paul Liu nine...@gmail.com wrote: Thanks. I've just built GHC HEAD on Mac OS X Lion, and tested by installing libraries with --enable-shared and loading a GLFW program into GHCi. Using ghci -fno-ghci-sandbox, everything works great including closing and restarting GL window multiple times. Can't wait for the official release of GHC 7.8! On Tue, Oct 1, 2013 at 12:09 PM, Carter Schonwald carter.schonw...@gmail.com wrote: thats the linker bug. the glfw stuff has been tested on ghc HEAD / 7.7 by folks on #haskell-game in recent memory. GHCI + foreign libs should work fine now (modulo thread local storage related thing). the historical element doesn't matter any more. To the best of my knowledge, all such issues should be gone. Anyone who cares about making sure GHCI+ gui libs play nice, PLEASE test with HEAD. the better this issue is properly tested (which i believe it has been), the more we can actually prevent it from happening. This requires people to test with HEAD GHCi now, rather than doing archaeology. anyone who cares, please play with GHCI in HEAD. If your lib doesn't work with ghci, please report a bug. It would be a new bug because it wont' be the previous reasons it hasnt' worked. tl;dr to the best of my knowledge this issue is resolved in HEAD. Test HEAD. Help us make sure it stays resolved by testing HEAD. thanks -Carter On Tue, Oct 1, 2013 at 1:20 PM, Paul Liu nine...@gmail.com wrote: I reported a problem with statically linked GLFW library on Mac OS X Lion in this thread: http://www.haskell.org/pipermail/haskell-cafe/2012-January/097355.html I do not know why this is broken on Mac OS X Lion, but not on Linux or Windows. There was an EnableGUI hack for GHC 7.2 (and previous versions) and OS X version before Lion, but it no longer works. So I'm not sure if it is OS X Lion, or GLFW, or GHC, or a combination of them that caused this problem. Regards, Paul Liu On Tue, Oct 1, 2013 at 7:04 AM, Carter Schonwald carter.schonw...@gmail.com wrote: Hey simon, the two issues that have recurrently bit ghci interaction with foreign GUI libs are 1) the ghci linker. This is fixed in head by now having ghci use the system linker 2) some GUI libs require thread local state, and ghci has a flag for that 3) I'm not aware of anyone reporting newly broken libs wrt GUI bindings when 7.6 rolled out. The only fix that's relevant to 7.8 is the dylinker bit, but that would have been a problem historically too. I believe a number of folks in #haskell-game have recently tested point one. (Though I should ask to double check) At the very least, I'm not aware of hearing of such a 7.6 specific ghci breakage before. On Tuesday, October 1, 2013, Simon Peyton-Jones wrote: Dear GHC devs See below (in red). I do not know the details of this, but it sounds like a pretty serious problem, and it used to work. Is whatever-it-is confirmed fixed in 7.8? Do we have a test that’ll trip if it breaks again? (I’m guessing that the latter might be hard.) Thanks Simon -Original Message- From: Haskell-Cafe [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Paul Liu Sent: 30 September 2013 07:18 To: Conal Elliott Cc: Haskell Cafe Subject: Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
of this, but it sounds like a pretty serious problem, and it used to work. Is whatever-it-is confirmed fixed in 7.8? Do we have a test that’ll trip if it breaks again? (I’m guessing that the latter might be hard.) Thanks Simon -Original Message- From: Haskell-Cafe [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Paul Liu Sent: 30 September 2013 07:18 To: Conal Elliott Cc: Haskell Cafe Subject: Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell Hi Conal, I wasn't able to make it to last Saturday's FARM track, but I think there was a good chance that Paul would have demonstrated his Euterpea music library, which includes a GUI interface (called MUI) written on top of GLFW. I wrote its initial implementation (around 2009?) with a monadic interface that let you wire together UI components with signals (I believe Dan later wrote an arrow interface, but I could be wrong). It was actually inspired by the ideas behind your Phooey UI library. It should be very easy to extract this part out as a standalone package if there is enough interest. The only issue with it (and all other UI libraries) is that it doesn't play nicely in GHCi. It used to work pretty well with GHC 7.2 and 7.4 on almost all platforms (Mac needs an extra hack), but GHC 7.6 broke Mac (and perhaps Windows too). GHC 7.8 supposedly should fix this problem. BTW, as also the author of the GLFW library on HackageDB, I've done barely minimal to keep this Haskell binding afloat. I'm actually leaning towards GLFW-b library, which is better maintained, and provides similar binding for GLFW C library but with a saner interface (no dependency on the OpenGL library, for example). If you don't need the two extra things that GLFW does (choice of either dynamic or static linking to GLFW C, and an embedded bitmap font), I suggest you try out GLFW-b if you are only looking for a think graphics layer with input+window+OpenGL. The only thing keeping GLFW-b from becoming a good foundation for a pure Haskell UI lib is IMHO the lack of a light-weight, cross-platform, and full-featured font rendering solution. I believe many other libraries (including Diagram) are having the same problem. On Thu, Sep 26, 2013 at 8:32 PM, Conal Elliott co...@conal.net wrote: I'm polling to see whether there are will and expertise to reboot graphics and GUIs work in Haskell. I miss working on functional graphics and GUIs in Haskell, as I've been blocked for several years (eight?) due to the absence of low-level foundation libraries having the following properties: * cross-platform, * easily buildable, * GHCi-friendly, and * OpenGL-compatible. The last several times I tried Gtk2hs, I was unable to compile it on my Mac. Years ago when I was able to compile, the GUIs looked and interacted like a Linux app, which made them awkward and upleasant to use. wxHaskell (whose API and visual appearance I prefered) has for years been incompatible with GHCi, in that the second time I open a top-level window, the host process (GHCi) dies abruptly. Since my GUI graphics programs are often one-liners, and I tend to experiment a lot, using a full compilation greatly thwarts my flow. For many years, I've thought that the situation would eventually improve, since I'm far from the only person who wants GUIs or graphics from Haskell. About three years ago, I built a modern replacement of my old Pan and V ___ ghc-devs mailing list ghc-d...@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Paul Liu -- Regards, Paul Liu ___ ghc-devs mailing list ghc-d...@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Paul Liu -- Regards, Paul Liu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
Hi Conal, I wasn't able to make it to last Saturday's FARM track, but I think there was a good chance that Paul would have demonstrated his Euterpea music library, which includes a GUI interface (called MUI) written on top of GLFW. I wrote its initial implementation (around 2009?) with a monadic interface that let you wire together UI components with signals (I believe Dan later wrote an arrow interface, but I could be wrong). It was actually inspired by the ideas behind your Phooey UI library. It should be very easy to extract this part out as a standalone package if there is enough interest. The only issue with it (and all other UI libraries) is that it doesn't play nicely in GHCi. It used to work pretty well with GHC 7.2 and 7.4 on almost all platforms (Mac needs an extra hack), but GHC 7.6 broke Mac (and perhaps Windows too). GHC 7.8 supposedly should fix this problem. BTW, as also the author of the GLFW library on HackageDB, I've done barely minimal to keep this Haskell binding afloat. I'm actually leaning towards GLFW-b library, which is better maintained, and provides similar binding for GLFW C library but with a saner interface (no dependency on the OpenGL library, for example). If you don't need the two extra things that GLFW does (choice of either dynamic or static linking to GLFW C, and an embedded bitmap font), I suggest you try out GLFW-b if you are only looking for a think graphics layer with input+window+OpenGL. The only thing keeping GLFW-b from becoming a good foundation for a pure Haskell UI lib is IMHO the lack of a light-weight, cross-platform, and full-featured font rendering solution. I believe many other libraries (including Diagram) are having the same problem. On Thu, Sep 26, 2013 at 8:32 PM, Conal Elliott co...@conal.net wrote: I'm polling to see whether there are will and expertise to reboot graphics and GUIs work in Haskell. I miss working on functional graphics and GUIs in Haskell, as I've been blocked for several years (eight?) due to the absence of low-level foundation libraries having the following properties: * cross-platform, * easily buildable, * GHCi-friendly, and * OpenGL-compatible. The last several times I tried Gtk2hs, I was unable to compile it on my Mac. Years ago when I was able to compile, the GUIs looked and interacted like a Linux app, which made them awkward and upleasant to use. wxHaskell (whose API and visual appearance I prefered) has for years been incompatible with GHCi, in that the second time I open a top-level window, the host process (GHCi) dies abruptly. Since my GUI graphics programs are often one-liners, and I tend to experiment a lot, using a full compilation greatly thwarts my flow. For many years, I've thought that the situation would eventually improve, since I'm far from the only person who wants GUIs or graphics from Haskell. About three years ago, I built a modern replacement of my old Pan and Vertigo systems (optimized high-level functional graphics in 2D and 3D), generating screamingly fast GPU rendering code. I'd love to share it with the community, but I'm unable to use it even myself. Two questions: * Am I mistaken about the current status? I.e., is there a solution for Haskell GUI graphics programming that satisfies the properties I'm looking for (cross-platform, easily buildable, GHCi-friendly, and OpenGL-compatible)? * Are there people willing and able to fix this situation? My own contributions would be to test and to share high-level composable and efficient GUI and graphics libraries on top of a working foundation. Looking forward to replies. Thanks, -- Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Regards, Paul Liu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
Hi Conrad, Great. The challenge is not specific to Pan, Vertigo, etc. If we can get some low-level GUI platform working with the characteristics I listed, I can resurrect and my high-level libraries accordingly. Any GUI program containing at least one OpenGL window would probably get us most of the way there (again, noting the properties I listed). -- Conal On Fri, Sep 27, 2013 at 1:40 AM, Conrad Parker con...@metadecks.org wrote: Hi Conal! Yes. I'd be very interested to help get Pan and Vertigo working. Do you have a repo somewhere? Conrad. On 27 September 2013 13:32, Conal Elliott co...@conal.net wrote: I'm polling to see whether there are will and expertise to reboot graphics and GUIs work in Haskell. I miss working on functional graphics and GUIs in Haskell, as I've been blocked for several years (eight?) due to the absence of low-level foundation libraries having the following properties: * cross-platform, * easily buildable, * GHCi-friendly, and * OpenGL-compatible. The last several times I tried Gtk2hs, I was unable to compile it on my Mac. Years ago when I was able to compile, the GUIs looked and interacted like a Linux app, which made them awkward and upleasant to use. wxHaskell (whose API and visual appearance I prefered) has for years been incompatible with GHCi, in that the second time I open a top-level window, the host process (GHCi) dies abruptly. Since my GUI graphics programs are often one-liners, and I tend to experiment a lot, using a full compilation greatly thwarts my flow. For many years, I've thought that the situation would eventually improve, since I'm far from the only person who wants GUIs or graphics from Haskell. About three years ago, I built a modern replacement of my old Pan and Vertigo systems (optimized high-level functional graphics in 2D and 3D), generating screamingly fast GPU rendering code. I'd love to share it with the community, but I'm unable to use it even myself. Two questions: * Am I mistaken about the current status? I.e., is there a solution for Haskell GUI graphics programming that satisfies the properties I'm looking for (cross-platform, easily buildable, GHCi-friendly, and OpenGL-compatible)? * Are there people willing and able to fix this situation? My own contributions would be to test and to share high-level composable and efficient GUI and graphics libraries on top of a working foundation. Looking forward to replies. Thanks, -- Conal ___ 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
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
On Fri, Sep 27, 2013 at 9:02 AM, Conal Elliott co...@conal.net wrote:
I'm polling to see whether there are will and expertise to reboot graphics
and GUIs work in Haskell. I miss working on functional graphics and GUIs in
Haskell, as I've been blocked for several years (eight?) due to the absence
of low-level foundation libraries having the following properties:
[Disclaimer: In accordance with the principle that the amount that one
speaks should be in proportion to the amount one knows, about GUI toolkits
I should say nothing . Just offering my thoughts, more on the side of
things I know -- programming languages and their history -- than not!]
When I first heard of perl (early 90s) the claim was that the same
language ran on Unix and DOS. I was incredulous. Implicitly I believed that
the only program that could run unchanged on 'never-the-twain-shall-meet'
territory was something that tended to the limiting the null program:
main() {}
What perl showed and the benchmark set for all the following scripting --
Ruby, Python etc -- revolution was that the old idea of C's portability had
given way to a new one. In the C world portability meant simply passively
avoiding non-portable features, in the new scripting world it meant
actively writing bridge code to reunite gratuitous differences: eg the
'universal newline' in some languages like python.
In short: The C world had given up on portability.
The scripting language world chose to bite the bullet
That choice may be a bigger factor in their success than people realize.
So my point for the GUI question is this: In addition to Conal's list
* cross-platform,
* easily buildable,
* GHCi-friendly, and
* OpenGL-compatible.
there are two other current holy-grails to chase:
a. Browser-Desktop portability: eg pyjamas
http://en.wikipedia.org/wiki/Pyjamas_%28software%29
b. Touch devices allowing for 'Natural user interface'[1]: Generalizing the
40 year old mouse-model to modern touch devices eg
http://kivy.org/#home
How difficult/doable is this? As I said, I am too much of an ignoramus to
know.
Hopefully the perl/scripting-language example will prompt more
knowledgeable/capable persons to at least consider the possibility of
chewing on a bullet…
[1] http://en.wikipedia.org/wiki/Natural_User_Interface
Rusi
--
http://blog.languager.org
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
Hi Conal, hi café, I'm currently devoting most of my time to this and plan to continue doing so (in the form of a PhD and work via my company). I've been working on a thorough review of the current status and a comparative analysis (using a fairly demanding, well-known algorithm to compare several aspects of different frameworks, including performance, readability, etc.) I can't give deadlines wrt. when things will be published, but would be happy to keep in touch with other people who are interested in this area of FP. Regards Ivan On 27 September 2013 05:32, Conal Elliott co...@conal.net wrote: I'm polling to see whether there are will and expertise to reboot graphics and GUIs work in Haskell. I miss working on functional graphics and GUIs in Haskell, as I've been blocked for several years (eight?) due to the absence of low-level foundation libraries having the following properties: * cross-platform, * easily buildable, * GHCi-friendly, and * OpenGL-compatible. The last several times I tried Gtk2hs, I was unable to compile it on my Mac. Years ago when I was able to compile, the GUIs looked and interacted like a Linux app, which made them awkward and upleasant to use. wxHaskell (whose API and visual appearance I prefered) has for years been incompatible with GHCi, in that the second time I open a top-level window, the host process (GHCi) dies abruptly. Since my GUI graphics programs are often one-liners, and I tend to experiment a lot, using a full compilation greatly thwarts my flow. For many years, I've thought that the situation would eventually improve, since I'm far from the only person who wants GUIs or graphics from Haskell. About three years ago, I built a modern replacement of my old Pan and Vertigo systems (optimized high-level functional graphics in 2D and 3D), generating screamingly fast GPU rendering code. I'd love to share it with the community, but I'm unable to use it even myself. Two questions: * Am I mistaken about the current status? I.e., is there a solution for Haskell GUI graphics programming that satisfies the properties I'm looking for (cross-platform, easily buildable, GHCi-friendly, and OpenGL-compatible)? * Are there people willing and able to fix this situation? My own contributions would be to test and to share high-level composable and efficient GUI and graphics libraries on top of a working foundation. Looking forward to replies. Thanks, -- Conal ___ 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
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
Hi Conal, If there is a system like you describe, I'm not aware of it. Part of the problem is the state of the underlying C libraries: gtk+ - possible, but suffers from the drawbacks you mention on OSX and is reportedly difficult to install on windows wx - somehow I've never been able to build this to my satisfaction on OSX (meaning a 64-bit build with working wxHaskell) QT - never tried this, but my impression is the Haskell-QT bindings are a bit stale FLTK is probably the surest approach, but it will definitely not look like a native Mac app. IMHO FLTK is hideously ugly on any system. But it is relatively easy to build. How much windowing are you looking for? Would GLFW be an acceptable starting point? John L. On Fri, Sep 27, 2013 at 12:40 AM, Conrad Parker con...@metadecks.orgwrote: Hi Conal! Yes. I'd be very interested to help get Pan and Vertigo working. Do you have a repo somewhere? Conrad. On 27 September 2013 13:32, Conal Elliott co...@conal.net wrote: I'm polling to see whether there are will and expertise to reboot graphics and GUIs work in Haskell. I miss working on functional graphics and GUIs in Haskell, as I've been blocked for several years (eight?) due to the absence of low-level foundation libraries having the following properties: * cross-platform, * easily buildable, * GHCi-friendly, and * OpenGL-compatible. The last several times I tried Gtk2hs, I was unable to compile it on my Mac. Years ago when I was able to compile, the GUIs looked and interacted like a Linux app, which made them awkward and upleasant to use. wxHaskell (whose API and visual appearance I prefered) has for years been incompatible with GHCi, in that the second time I open a top-level window, the host process (GHCi) dies abruptly. Since my GUI graphics programs are often one-liners, and I tend to experiment a lot, using a full compilation greatly thwarts my flow. For many years, I've thought that the situation would eventually improve, since I'm far from the only person who wants GUIs or graphics from Haskell. About three years ago, I built a modern replacement of my old Pan and Vertigo systems (optimized high-level functional graphics in 2D and 3D), generating screamingly fast GPU rendering code. I'd love to share it with the community, but I'm unable to use it even myself. Two questions: * Am I mistaken about the current status? I.e., is there a solution for Haskell GUI graphics programming that satisfies the properties I'm looking for (cross-platform, easily buildable, GHCi-friendly, and OpenGL-compatible)? * Are there people willing and able to fix this situation? My own contributions would be to test and to share high-level composable and efficient GUI and graphics libraries on top of a working foundation. Looking forward to replies. Thanks, -- Conal ___ 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
i know nothing on the gui tooling front, but i do know this: the ffi linking issues with GHCI *should* be fixed with ghc HEAD / 7.8. If you have linking problems with GHCi HEAD, please report it ASAP. All linking related issues that have historically plagued ghci should be resolved, at least on platforms where theres support for dynamic linking for ghc On Thu, Sep 26, 2013 at 11:32 PM, Conal Elliott co...@conal.net wrote: I'm polling to see whether there are will and expertise to reboot graphics and GUIs work in Haskell. I miss working on functional graphics and GUIs in Haskell, as I've been blocked for several years (eight?) due to the absence of low-level foundation libraries having the following properties: * cross-platform, * easily buildable, * GHCi-friendly, and * OpenGL-compatible. The last several times I tried Gtk2hs, I was unable to compile it on my Mac. Years ago when I was able to compile, the GUIs looked and interacted like a Linux app, which made them awkward and upleasant to use. wxHaskell (whose API and visual appearance I prefered) has for years been incompatible with GHCi, in that the second time I open a top-level window, the host process (GHCi) dies abruptly. Since my GUI graphics programs are often one-liners, and I tend to experiment a lot, using a full compilation greatly thwarts my flow. For many years, I've thought that the situation would eventually improve, since I'm far from the only person who wants GUIs or graphics from Haskell. About three years ago, I built a modern replacement of my old Pan and Vertigo systems (optimized high-level functional graphics in 2D and 3D), generating screamingly fast GPU rendering code. I'd love to share it with the community, but I'm unable to use it even myself. Two questions: * Am I mistaken about the current status? I.e., is there a solution for Haskell GUI graphics programming that satisfies the properties I'm looking for (cross-platform, easily buildable, GHCi-friendly, and OpenGL-compatible)? * Are there people willing and able to fix this situation? My own contributions would be to test and to share high-level composable and efficient GUI and graphics libraries on top of a working foundation. Looking forward to replies. Thanks, -- Conal ___ 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
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
John Lato jwl...@gmail.com writes: QT - never tried this, but my impression is the Haskell-QT bindings are a bit stale Yes, QtHaskell [1] has been inactive for three years, as far as I can tell. However, there are newish bindings [2] for the Qt Quick declarative UI stuff that's appeared in recent Qt versions -- see the package hsqml on hackage [3]. It hasn't had any new uploads to hackage since last year, but there was activity on its repo as recently as yesterday [4]. I've yet to see any applications built on it, but it looks exciting. -Keshav [1] http://qthaskell.berlios.de/ [2] http://www.gekkou.co.uk/software/hsqml/ [3] http://hackage.haskell.org/package/hsqml [4] http://patch-tag.com/r/komadori/HsQML/snapshots/all/history ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
Conal Elliott wrote: I'm polling to see whether there are will and expertise to reboot graphics and GUIs work in Haskell. I miss working on functional graphics and GUIs in Haskell, as I've been blocked for several years (eight?) due to the absence of low-level foundation libraries having the following properties: * cross-platform, * easily buildable, * GHCi-friendly, and * OpenGL-compatible. The last several times I tried Gtk2hs, I was unable to compile it on my Mac. Years ago when I was able to compile, the GUIs looked and interacted like a Linux app, which made them awkward and upleasant to use. wxHaskell (whose API and visual appearance I prefered) has for years been incompatible with GHCi, in that the second time I open a top-level window, the host process (GHCi) dies abruptly. Since my GUI graphics programs are often one-liners, and I tend to experiment a lot, using a full compilation greatly thwarts my flow. For many years, I've thought that the situation would eventually improve, since I'm far from the only person who wants GUIs or graphics from Haskell. About three years ago, I built a modern replacement of my old Pan and Vertigo systems (optimized high-level functional graphics in 2D and 3D), generating screamingly fast GPU rendering code. I'd love to share it with the community, but I'm unable to use it even myself. Two questions: * Am I mistaken about the current status? I.e., is there a solution for Haskell GUI graphics programming that satisfies the properties I'm looking for (cross-platform, easily buildable, GHCi-friendly, and OpenGL-compatible)? * Are there people willing and able to fix this situation? My own contributions would be to test and to share high-level composable and efficient GUI and graphics libraries on top of a working foundation. Hello Conal, I have been similarly dissatisfied with the state of GUI libraries in Haskell and have finally started working on one myself: [threepenny-gui][1]. Threepenny-gui uses the web browser as a display, which means that it's cross-platform, easy to install and works from GHCi! On the flip side, it doesn't support native OpenGL. [1]: http://www.haskell.org/haskellwiki/Threepenny-gui Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
Could threepenny work with webGL, or is that too far out of the scope of the project? I guess the overhead of having a server--even locally--and using a web browser might just be too much for many use cases. On Sep 27, 2013 1:51 AM, Heinrich Apfelmus apfel...@quantentunnel.de wrote: Conal Elliott wrote: I'm polling to see whether there are will and expertise to reboot graphics and GUIs work in Haskell. I miss working on functional graphics and GUIs in Haskell, as I've been blocked for several years (eight?) due to the absence of low-level foundation libraries having the following properties: * cross-platform, * easily buildable, * GHCi-friendly, and * OpenGL-compatible. The last several times I tried Gtk2hs, I was unable to compile it on my Mac. Years ago when I was able to compile, the GUIs looked and interacted like a Linux app, which made them awkward and upleasant to use. wxHaskell (whose API and visual appearance I prefered) has for years been incompatible with GHCi, in that the second time I open a top-level window, the host process (GHCi) dies abruptly. Since my GUI graphics programs are often one-liners, and I tend to experiment a lot, using a full compilation greatly thwarts my flow. For many years, I've thought that the situation would eventually improve, since I'm far from the only person who wants GUIs or graphics from Haskell. About three years ago, I built a modern replacement of my old Pan and Vertigo systems (optimized high-level functional graphics in 2D and 3D), generating screamingly fast GPU rendering code. I'd love to share it with the community, but I'm unable to use it even myself. Two questions: * Am I mistaken about the current status? I.e., is there a solution for Haskell GUI graphics programming that satisfies the properties I'm looking for (cross-platform, easily buildable, GHCi-friendly, and OpenGL-compatible)? * Are there people willing and able to fix this situation? My own contributions would be to test and to share high-level composable and efficient GUI and graphics libraries on top of a working foundation. Hello Conal, I have been similarly dissatisfied with the state of GUI libraries in Haskell and have finally started working on one myself: [threepenny-gui][1]. Threepenny-gui uses the web browser as a display, which means that it's cross-platform, easy to install and works from GHCi! On the flip side, it doesn't support native OpenGL. [1]: http://www.haskell.org/**haskellwiki/Threepenny-guihttp://www.haskell.org/haskellwiki/Threepenny-gui Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com __**_ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
However, I would prefer to have two different types of libraries in haskell: For graphics, something like SFML or SDL, no GUI implicit. but with good/modern OpenGL. Maybe we won't need a direct binding, but rethinking who should be done a SDL-like library in Haskell. Yep, FRP is cool, but need clever people. Whenever I try to do a pet-game with that.. I always come back to C++. And for GUI, I had good feeling of gtk bindings in the past. Luis On Fri, Sep 27, 2013 at 5:32 AM, Conal Elliott co...@conal.net wrote: I'm polling to see whether there are will and expertise to reboot graphics and GUIs work in Haskell. I miss working on functional graphics and GUIs in Haskell, as I've been blocked for several years (eight?) due to the absence of low-level foundation libraries having the following properties: * cross-platform, * easily buildable, * GHCi-friendly, and * OpenGL-compatible. The last several times I tried Gtk2hs, I was unable to compile it on my Mac. Years ago when I was able to compile, the GUIs looked and interacted like a Linux app, which made them awkward and upleasant to use. wxHaskell (whose API and visual appearance I prefered) has for years been incompatible with GHCi, in that the second time I open a top-level window, the host process (GHCi) dies abruptly. Since my GUI graphics programs are often one-liners, and I tend to experiment a lot, using a full compilation greatly thwarts my flow. For many years, I've thought that the situation would eventually improve, since I'm far from the only person who wants GUIs or graphics from Haskell. About three years ago, I built a modern replacement of my old Pan and Vertigo systems (optimized high-level functional graphics in 2D and 3D), generating screamingly fast GPU rendering code. I'd love to share it with the community, but I'm unable to use it even myself. Two questions: * Am I mistaken about the current status? I.e., is there a solution for Haskell GUI graphics programming that satisfies the properties I'm looking for (cross-platform, easily buildable, GHCi-friendly, and OpenGL-compatible)? * Are there people willing and able to fix this situation? My own contributions would be to test and to share high-level composable and efficient GUI and graphics libraries on top of a working foundation. Looking forward to replies. Thanks, -- Conal ___ 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
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
Tikhon Jelvis wrote: Could threepenny work with webGL, or is that too far out of the scope of the project? I guess the overhead of having a server--even locally--and using a web browser might just be too much for many use cases. Actually, I'm reading about WebGL right now, and it appears to me that it should be very easy to support in Threepenny. While the communication between browser and server is comparatively slow, most of the hard work is done in the shading language anyway. The browser retrieves shading code from a `script` tag. It's straightforward to create such a tag in Threepenny, populate it, and make a few JavaScript FFI calls to start the rendering process. I currently have no plans to add WebGL support myself, but all the ingredients are in place. (Maybe wait until threepenny-0.4 , as I'm currently simplifying the FFI a bit.) PS: Conal, if you want to see whether the Threepenny + WebGL route is viable for you, it's probably a good idea to do a quick test in plain HTML + JS first, to see whether performance is good enough for your purpose. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
On 09/27/2013 04:32 AM, Conal Elliott wrote: I'm polling to see whether there are will and expertise to reboot graphics and GUIs work in Haskell. I miss working on functional graphics and GUIs in Haskell, as I've been blocked for several years (eight?) due to the absence of low-level foundation libraries having the following properties: * cross-platform, * easily buildable, * GHCi-friendly, and * OpenGL-compatible. The last several times I tried Gtk2hs, I was unable to compile it on my Mac. Years ago when I was able to compile, the GUIs looked and interacted like a Linux app, which made them awkward and upleasant to use. wxHaskell (whose API and visual appearance I prefered) has for years been incompatible with GHCi, in that the second time I open a top-level window, the host process (GHCi) dies abruptly. Since my GUI graphics programs are often one-liners, and I tend to experiment a lot, using a full compilation greatly thwarts my flow. For many years, I've thought that the situation would eventually improve, since I'm far from the only person who wants GUIs or graphics from Haskell. We are working on bindings to SDL 2 at the moment - https://github.com/Lemmih/hsSDL2. They are currently usable for most 'stock' work - drawing things, doing interaction, window management, etc. However, I'm afraid SDL bindings don't really solve what you want in terms of a GUI programming. SDL2 at least gives you a sane cross platform way to create a window with an OpenGL context, and to draw things using hardware acceleration. If you actually need widgets, then SDL probably won't help here. - ocharles signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
Hello, Keshav Kini wrote: [snip] However, there are newish bindings [2] for the Qt Quick declarative UI stuff that's appeared in recent Qt versions -- see the package hsqml on hackage [3]. It hasn't had any new uploads to hackage since last year, but there was activity on its repo as recently as yesterday [4]. I've yet to see any applications built on it, but it looks exciting. Yes, I'm afraid I've been failing to embrace the release early release often mantra with HsQML. I originally set myself some (fairly modest) goals for the next release. Unfortunately, I've had less time to spend on it than I'd like and it's delayed getting there. There has been a fair amount of interest via e-mail, but the dearth of releases has probably dissuaded people from using it. Also, I need to write more documentation and provide better examples. That said, I've got a ticket to the Haskell eXchange in London next month and I set myself a personal deadline of making a new release before then. So, having said that in public, I'll have to really try and keep to it ^_^'! The next release will add support for Qt signals, plus bug fixes and Mac support. For the next release after that, I plan to port the library to Qt 5. Regards, -- Robin KAY ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
Robin KAY komad...@gekkou.co.uk writes: Yes, I'm afraid I've been failing to embrace the release early release often mantra with HsQML. I originally set myself some (fairly modest) goals for the next release. Unfortunately, I've had less time to spend on it than I'd like and it's delayed getting there. There has been a fair amount of interest via e-mail, but the dearth of releases has probably dissuaded people from using it. Also, I need to write more documentation and provide better examples. That said, I've got a ticket to the Haskell eXchange in London next month and I set myself a personal deadline of making a new release before then. So, having said that in public, I'll have to really try and keep to it ^_^'! The next release will add support for Qt signals, plus bug fixes and Mac support. For the next release after that, I plan to port the library to Qt 5. Awesome! Thanks, Robin! -Keshav ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
On Thu, Sep 26, 2013 at 8:32 PM, Conal Elliott co...@conal.net wrote: I'm polling to see whether there are will and expertise to reboot graphics and GUIs work in Haskell. I miss working on functional graphics and GUIs in Haskell, as I've been blocked for several years (eight?) due to the absence of low-level foundation libraries having the following properties: * cross-platform, * easily buildable, * GHCi-friendly, and * OpenGL-compatible. GLFW-b satisfies all of these. There are two caveats: a) to use it with GHCi you'll need to use ghc 7.8 (when it comes out in a week or two); b) it's really only providing an OpenGL context and none of the other traditional GUI things like widgets and font rendering. As far as GHCi compatibility is concerned, the problem there isn't with GLFW or the Haskell bindings. GHCi has been toxic to these sorts of libraries for a long time due to some bugs and limitations. In GHC 7.8, there is a change to use the system wide linker by default and that removes one hurdle. The next hurdle is to make GHCi work better with libraries that use thread local storage that is pinned to the process's original thread. You can often workaround this limitation with -fghci-no-sandbox. The last several times I tried Gtk2hs, I was unable to compile it on my Mac. Years ago when I was able to compile, the GUIs looked and interacted like a Linux app, which made them awkward and upleasant to use. wxHaskell (whose API and visual appearance I prefered) has for years been incompatible with GHCi, in that the second time I open a top-level window, the host process (GHCi) dies abruptly. Since my GUI graphics programs are often one-liners, and I tend to experiment a lot, using a full compilation greatly thwarts my flow. For many years, I've thought that the situation would eventually improve, since I'm far from the only person who wants GUIs or graphics from Haskell. wxHaskell + GHCi is likely affected by some of the things I mention above. You should give it another try when 7.8 lands. I hope that helps, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
On Fri, 27 Sep 2013 05:32:18 +0200, Conal Elliott co...@conal.net wrote: I'm polling to see whether there are will and expertise to reboot graphics and GUIs work in Haskell. : * cross-platform, * easily buildable, * GHCi-friendly, and * OpenGL-compatible. : wxHaskell (whose API and visual appearance I prefered) has for years been incompatible with GHCi, in that the second time I open a top-level window, the host process (GHCi) dies abruptly. : * Am I mistaken about the current status? I.e., is there a solution for Haskell GUI graphics programming that satisfies the properties I'm looking for (cross-platform, easily buildable, GHCi-friendly, and OpenGL-compatible)? * Are there people willing and able to fix this situation? My own contributions would be to test and to share high-level composable and efficient GUI and graphics libraries on top of a working foundation. - wxHaskell is now actively maintained; several people have contributed new functionality and solutions to bugs. I hope there will be more people to help squash bugs, extend functionality and make the installation procedure easier. - The problems with GHCi will probably be solved with GHC 7.8. - OpenGL is supported Regards, Henk-Jan van Tuyl -- Folding@home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
I'm polling to see whether there are will and expertise to reboot graphics and GUIs work in Haskell. I miss working on functional graphics and GUIs in Haskell, as I've been blocked for several years (eight?) due to the absence of low-level foundation libraries having the following properties: * cross-platform, * easily buildable, * GHCi-friendly, and * OpenGL-compatible. The last several times I tried Gtk2hs, I was unable to compile it on my Mac. Years ago when I was able to compile, the GUIs looked and interacted like a Linux app, which made them awkward and upleasant to use. wxHaskell (whose API and visual appearance I prefered) has for years been incompatible with GHCi, in that the second time I open a top-level window, the host process (GHCi) dies abruptly. Since my GUI graphics programs are often one-liners, and I tend to experiment a lot, using a full compilation greatly thwarts my flow. For many years, I've thought that the situation would eventually improve, since I'm far from the only person who wants GUIs or graphics from Haskell. About three years ago, I built a modern replacement of my old Pan and Vertigo systems (optimized high-level functional graphics in 2D and 3D), generating screamingly fast GPU rendering code. I'd love to share it with the community, but I'm unable to use it even myself. Two questions: * Am I mistaken about the current status? I.e., is there a solution for Haskell GUI graphics programming that satisfies the properties I'm looking for (cross-platform, easily buildable, GHCi-friendly, and OpenGL-compatible)? * Are there people willing and able to fix this situation? My own contributions would be to test and to share high-level composable and efficient GUI and graphics libraries on top of a working foundation. Looking forward to replies. Thanks, -- Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
Hi Conal, I'm glad you're bringing this up. I am currently working on FLTK bindings ( github.com/deech/fltkhs). It's main advantage of this toolkit is that it lets the user deploy apps as a self-contained binary on all platforms. Right now the work consists of the tedium of binding Haskell to the underlying C layer. Any help with the grunt work or input on creating a nice Haskell API would be appreciated. So far it seems as though wxHaskell is worth emulating but I'm pretty open. Thanks! -deech On Thu, Sep 26, 2013 at 10:32 PM, Conal Elliott co...@conal.net wrote: I'm polling to see whether there are will and expertise to reboot graphics and GUIs work in Haskell. I miss working on functional graphics and GUIs in Haskell, as I've been blocked for several years (eight?) due to the absence of low-level foundation libraries having the following properties: * cross-platform, * easily buildable, * GHCi-friendly, and * OpenGL-compatible. The last several times I tried Gtk2hs, I was unable to compile it on my Mac. Years ago when I was able to compile, the GUIs looked and interacted like a Linux app, which made them awkward and upleasant to use. wxHaskell (whose API and visual appearance I prefered) has for years been incompatible with GHCi, in that the second time I open a top-level window, the host process (GHCi) dies abruptly. Since my GUI graphics programs are often one-liners, and I tend to experiment a lot, using a full compilation greatly thwarts my flow. For many years, I've thought that the situation would eventually improve, since I'm far from the only person who wants GUIs or graphics from Haskell. About three years ago, I built a modern replacement of my old Pan and Vertigo systems (optimized high-level functional graphics in 2D and 3D), generating screamingly fast GPU rendering code. I'd love to share it with the community, but I'm unable to use it even myself. Two questions: * Am I mistaken about the current status? I.e., is there a solution for Haskell GUI graphics programming that satisfies the properties I'm looking for (cross-platform, easily buildable, GHCi-friendly, and OpenGL-compatible)? * Are there people willing and able to fix this situation? My own contributions would be to test and to share high-level composable and efficient GUI and graphics libraries on top of a working foundation. Looking forward to replies. Thanks, -- Conal ___ 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
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
What does the following mean? About three years ago, I built a modern replacement of my old Pan and Vertigo systems (optimized high-level functional graphics in 2D and 3D), generating screamingly fast GPU rendering code. I'd love to share it with the community, but I'm unable to use it even myself. Casey On Thu, Sep 26, 2013 at 8:32 PM, Conal Elliott co...@conal.net wrote: I'm polling to see whether there are will and expertise to reboot graphics and GUIs work in Haskell. I miss working on functional graphics and GUIs in Haskell, as I've been blocked for several years (eight?) due to the absence of low-level foundation libraries having the following properties: * cross-platform, * easily buildable, * GHCi-friendly, and * OpenGL-compatible. The last several times I tried Gtk2hs, I was unable to compile it on my Mac. Years ago when I was able to compile, the GUIs looked and interacted like a Linux app, which made them awkward and upleasant to use. wxHaskell (whose API and visual appearance I prefered) has for years been incompatible with GHCi, in that the second time I open a top-level window, the host process (GHCi) dies abruptly. Since my GUI graphics programs are often one-liners, and I tend to experiment a lot, using a full compilation greatly thwarts my flow. For many years, I've thought that the situation would eventually improve, since I'm far from the only person who wants GUIs or graphics from Haskell. About three years ago, I built a modern replacement of my old Pan and Vertigo systems (optimized high-level functional graphics in 2D and 3D), generating screamingly fast GPU rendering code. I'd love to share it with the community, but I'm unable to use it even myself. Two questions: * Am I mistaken about the current status? I.e., is there a solution for Haskell GUI graphics programming that satisfies the properties I'm looking for (cross-platform, easily buildable, GHCi-friendly, and OpenGL-compatible)? * Are there people willing and able to fix this situation? My own contributions would be to test and to share high-level composable and efficient GUI and graphics libraries on top of a working foundation. Looking forward to replies. Thanks, -- Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- -- Regards, KC ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
Hi Conal! Yes. I'd be very interested to help get Pan and Vertigo working. Do you have a repo somewhere? Conrad. On 27 September 2013 13:32, Conal Elliott co...@conal.net wrote: I'm polling to see whether there are will and expertise to reboot graphics and GUIs work in Haskell. I miss working on functional graphics and GUIs in Haskell, as I've been blocked for several years (eight?) due to the absence of low-level foundation libraries having the following properties: * cross-platform, * easily buildable, * GHCi-friendly, and * OpenGL-compatible. The last several times I tried Gtk2hs, I was unable to compile it on my Mac. Years ago when I was able to compile, the GUIs looked and interacted like a Linux app, which made them awkward and upleasant to use. wxHaskell (whose API and visual appearance I prefered) has for years been incompatible with GHCi, in that the second time I open a top-level window, the host process (GHCi) dies abruptly. Since my GUI graphics programs are often one-liners, and I tend to experiment a lot, using a full compilation greatly thwarts my flow. For many years, I've thought that the situation would eventually improve, since I'm far from the only person who wants GUIs or graphics from Haskell. About three years ago, I built a modern replacement of my old Pan and Vertigo systems (optimized high-level functional graphics in 2D and 3D), generating screamingly fast GPU rendering code. I'd love to share it with the community, but I'm unable to use it even myself. Two questions: * Am I mistaken about the current status? I.e., is there a solution for Haskell GUI graphics programming that satisfies the properties I'm looking for (cross-platform, easily buildable, GHCi-friendly, and OpenGL-compatible)? * Are there people willing and able to fix this situation? My own contributions would be to test and to share high-level composable and efficient GUI and graphics libraries on top of a working foundation. Looking forward to replies. Thanks, -- Conal ___ 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
