Re: [Haskell-cafe] Poll & plea: State of GUI & graphics libraries in Haskell

[Heinrich Apfelmus]

Sven Panne wrote:

2013/9/27 Heinrich Apfelmus :

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

[Heinrich Apfelmus]

Sven Panne wrote:

2013/9/27 Conal Elliott :

[...] 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

[John Lato]

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"  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  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

[Sven Panne]

2013/9/27 Conal Elliott :
> [...] 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

[Sven Panne]

2013/9/27 Heinrich Apfelmus :
> 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

[Henk-Jan van Tuyl]

On Wed, 02 Oct 2013 12:24:25 +0200, Atze Dijkstra  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

[Alp Mestanogullari]

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  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

Re: [Haskell-cafe] Poll & plea: State of GUI & graphics libraries in Haskell

[Robin KAY]

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

[Alp Mestanogullari]

ny 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 
>>>> 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
>>>> >> >>  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
>>>> >> >> >>
>>>> >> >> >>
>>>> >> >> >

Re: [Haskell-cafe] Poll & plea: State of GUI & graphics libraries in Haskell

[Jake McArthur]

> >> > 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  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
>>> >> >>  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
>>> >> >&g

Re: [Haskell-cafe] Poll & plea: State of GUI & graphics libraries in Haskell

[Alp Mestanogullari]

hy 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
>> >> >>  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
>> >> >&

Re: [Haskell-cafe] Poll & plea: State of GUI & graphics libraries in Haskell

[Paul Liu]

> >> 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
>> >> >>  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
>> >> >&g

Re: [Haskell-cafe] Poll & plea: State of GUI & graphics libraries in Haskell

[Conal Elliott]

d 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.
> >> >> >>
&g

Re: [Haskell-cafe] Poll & plea: State of GUI & graphics libraries in Haskell

[Paul Liu]

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  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  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
>>  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  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
>> >>  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
>> >>

Re: [Haskell-cafe] Poll & plea: State of GUI & graphics libraries in Haskell

[Simon Marlow]

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
 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  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
 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 

Re: [Haskell-cafe] Poll & plea: State of GUI & graphics libraries in Haskell

[Conal Elliott]

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  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
>  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  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
> >>  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: Haske

Re: [Haskell-cafe] Poll & plea: State of GUI & graphics libraries in Haskell

[Conal Elliott]

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  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  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 
> 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  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

[Sylvain HENRY]

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=about&l=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

[Atze Dijkstra]

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  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  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  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

[Carter Schonwald]

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
>  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  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
> >>  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

[Paul Liu]

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
 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  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
>>  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 in

Re: [Haskell-cafe] Poll & plea: State of GUI & graphics libraries in Haskell

[Conal Elliott]

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  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  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

[Paul Liu]

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  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

[Ivan Perez]

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  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

[Rustom Mody]

On Fri, Sep 27, 2013 at 9:02 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:
>
> [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

[Henk-Jan van Tuyl]

On Fri, 27 Sep 2013 05:32:18 +0200, Conal Elliott  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

Re: [Haskell-cafe] Poll & plea: State of GUI & graphics libraries in Haskell

[Jason Dagit]

On Thu, Sep 26, 2013 at 8:32 PM, 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.
>

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

[Keshav Kini]

Robin KAY  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

[Robin KAY]

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

[Oliver Charles]

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

[Heinrich Apfelmus]

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

[Luis Cabellos]

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  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]

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" 
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-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
>
___
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

[Heinrich Apfelmus]

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

[Keshav Kini]

John Lato  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

[Carter Schonwald]

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  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]

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 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  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

[Conrad Parker]

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  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

[KC]

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  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

[aditya siram]

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  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