Poll & plea: State of GUI & graphics libraries in Haskell

newer
Converting MPTC+fundeps to type...

Conal Elliott

26 Sep 2013 26 Sep '13

11:32 p.m.

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

Attachments:

attachment.html (text/html — 1.9 KB)

Show replies by date

aditya siram

26 Sep 26 Sep

11:39 p.m.

New subject: Poll & plea: State of GUI & graphics libraries in Haskell

Hi Conal, I'm glad you're bringing this up. I am currently working on FLTK bindings ( github.com/deech/fltkhs). It's main advantage of this toolkit is that it lets the user deploy apps as a self-contained binary on all platforms. Right now the work consists of the tedium of binding Haskell to the underlying C layer. Any help with the grunt work or input on creating a nice Haskell API would be appreciated. So far it seems as though wxHaskell is worth emulating but I'm pretty open. Thanks! -deech On Thu, Sep 26, 2013 at 10:32 PM, Conal Elliott 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

KC

11:52 p.m.

New subject: Poll & plea: State of GUI & graphics libraries in Haskell

What does the following mean? About three years ago, I built a modern replacement of my old Pan and Vertigo systems (optimized high-level functional graphics in 2D and 3D), generating screamingly fast GPU rendering code. I'd love to share it with the community, but I'm unable to use it even myself. Casey On Thu, Sep 26, 2013 at 8:32 PM, Conal Elliott 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

Conrad Parker

27 Sep 27 Sep

1:40 a.m.

New subject: Poll & plea: State of GUI & graphics libraries in Haskell

Hi Conal! Yes. I'd be very interested to help get Pan and Vertigo working. Do you have a repo somewhere? Conrad. On 27 September 2013 13:32, Conal Elliott 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

John Lato

2:03 a.m.

New subject: Poll & plea: State of GUI & graphics libraries in Haskell

Hi Conal, If there is a system like you describe, I'm not aware of it. Part of the problem is the state of the underlying C libraries: gtk+ - possible, but suffers from the drawbacks you mention on OSX and is reportedly difficult to install on windows wx - somehow I've never been able to build this to my satisfaction on OSX (meaning a 64-bit build with working wxHaskell) QT - never tried this, but my impression is the Haskell-QT bindings are a bit stale FLTK is probably the surest approach, but it will definitely not look like a native Mac app. IMHO FLTK is hideously ugly on any system. But it is relatively easy to build. How much windowing are you looking for? Would GLFW be an acceptable starting point? John L. On Fri, Sep 27, 2013 at 12:40 AM, Conrad Parker 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

Keshav Kini

2:29 a.m.

New subject: Poll & plea: State of GUI & graphics libraries in Haskell

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

Robin KAY

6:26 a.m.

New subject: Poll & plea: State of GUI & graphics libraries in Haskell

Hello, Keshav Kini wrote: [snip]

...

However, there are newish bindings [2] for the Qt Quick declarative UI stuff that's appeared in recent Qt versions -- see the package "hsqml" on hackage [3]. It hasn't had any new uploads to hackage since last year, but there was activity on its repo as recently as yesterday [4]. I've yet to see any applications built on it, but it looks exciting.

Yes, I'm afraid I've been failing to embrace the release early release often mantra with HsQML. I originally set myself some (fairly modest) goals for the next release. Unfortunately, I've had less time to spend on it than I'd like and it's delayed getting there. There has been a fair amount of interest via e-mail, but the dearth of releases has probably dissuaded people from using it. Also, I need to write more documentation and provide better examples. That said, I've got a ticket to the Haskell eXchange in London next month and I set myself a personal deadline of making a new release before then. So, having said that in public, I'll have to really try and keep to it ^_^'! The next release will add support for Qt signals, plus bug fixes and Mac support. For the next release after that, I plan to port the library to Qt 5. Regards, -- Robin KAY

Keshav Kini

12:56 p.m.

New subject: Poll & plea: State of GUI & graphics libraries in Haskell

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

Conal Elliott

30 Sep 30 Sep

2:32 p.m.

New subject: Poll & plea: State of GUI & graphics libraries in Haskell

Hi Conrad, Great. The challenge is not specific to Pan, Vertigo, etc. If we can get some low-level GUI platform working with the characteristics I listed, I can resurrect and my high-level libraries accordingly. Any GUI program containing at least one OpenGL window would probably get us most of the way there (again, noting the properties I listed). -- Conal On Fri, Sep 27, 2013 at 1:40 AM, Conrad Parker 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

Atze Dijkstra

2 Oct 2 Oct

6:24 a.m.

New subject: Poll & plea: State of GUI & graphics libraries in Haskell

Hi, as for wxHaskell, it is currently maintained at https://github.com/wxHaskell/wxHaskell, compilable with wxWidgets 2.9.5 and GHC 7.6. Work is underway to fix various bugs introduced over time by changes in wxWidgets, but we (i.e. https://github.com/wxHaskell?tab=members) hope to release & announce in not too much time. cheers, Atze On 30 Sep, 2013, at 20:32 , Conal Elliott 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: atze@uu.nl ............... / |___\

Conal Elliott

11:38 a.m.

New subject: Poll & plea: State of GUI & graphics libraries in Haskell

Hi Atze. I'm glad to hear that some work is going into wxHaskell. Do you know about the issue that arose roughly 7-8 years ago that prevented opening more than one top-level window per process? It had to do with a change to initialization techniques, and made wxHaskell no longer useful with GHCi. -- Conal On Wed, Oct 2, 2013 at 3:24 AM, Atze Dijkstra 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: atze@uu.nl ............... / |___\

Henk-Jan van Tuyl

5 Oct 5 Oct

1:24 a.m.

New subject: Poll & plea: State of GUI & graphics libraries in Haskell

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

Carter Schonwald

27 Sep 27 Sep

2:03 a.m.

New subject: Poll & plea: State of GUI & graphics libraries in Haskell

i know nothing on the gui tooling front, but i do know this: the ffi linking issues with GHCI *should* be fixed with ghc HEAD / 7.8. If you have linking problems with GHCi HEAD, please report it ASAP. All linking related issues that have historically plagued ghci should be resolved, at least on platforms where theres support for dynamic linking for ghc On Thu, Sep 26, 2013 at 11:32 PM, Conal Elliott 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

Heinrich Apfelmus

4:51 a.m.

New subject: Poll & plea: State of GUI & graphics libraries in Haskell

Conal Elliott wrote:

...

I'm polling to see whether there are will and expertise to reboot graphics and GUIs work in Haskell. I miss working on functional graphics and GUIs in Haskell, as I've been blocked for several years (eight?) due to the absence of low-level foundation libraries having the following properties:

* cross-platform, * easily buildable, * GHCi-friendly, and * OpenGL-compatible.

The last several times I tried Gtk2hs, I was unable to compile it on my Mac. Years ago when I was able to compile, the GUIs looked and interacted like a Linux app, which made them awkward and upleasant to use. wxHaskell (whose API and visual appearance I prefered) has for years been incompatible with GHCi, in that the second time I open a top-level window, the host process (GHCi) dies abruptly. Since my GUI & graphics programs are often one-liners, and I tend to experiment a lot, using a full compilation greatly thwarts my flow. For many years, I've thought that the situation would eventually improve, since I'm far from the only person who wants GUIs or graphics from Haskell.

About three years ago, I built a modern replacement of my old Pan and Vertigo systems (optimized high-level functional graphics in 2D and 3D), generating screamingly fast GPU rendering code. I'd love to share it with the community, but I'm unable to use it even myself.

Two questions:

* Am I mistaken about the current status? I.e., is there a solution for Haskell GUI & graphics programming that satisfies the properties I'm looking for (cross-platform, easily buildable, GHCi-friendly, and OpenGL-compatible)? * Are there people willing and able to fix this situation? My own contributions would be to test and to share high-level composable and efficient GUI and graphics libraries on top of a working foundation.

Hello Conal, I have been similarly dissatisfied with the state of GUI libraries in Haskell and have finally started working on one myself: [threepenny-gui][1]. Threepenny-gui uses the web browser as a display, which means that it's cross-platform, easy to install and works from GHCi! On the flip side, it doesn't support native OpenGL. [1]: http://www.haskell.org/haskellwiki/Threepenny-gui Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com

Tikhon Jelvis

4:53 a.m.

New subject: Poll & plea: State of GUI & graphics libraries in Haskell

Could threepenny work with webGL, or is that too far out of the scope of the project? I guess the overhead of having a server--even locally--and using a web browser might just be too much for many use cases. On Sep 27, 2013 1:51 AM, "Heinrich Apfelmus" 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 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 http://www.haskell.org/mailman/listinfo/haskell-cafe

Heinrich Apfelmus

5:21 a.m.

New subject: Poll & plea: State of GUI & graphics libraries in Haskell

Tikhon Jelvis wrote:

...

Could threepenny work with webGL, or is that too far out of the scope of the project? I guess the overhead of having a server--even locally--and using a web browser might just be too much for many use cases.

Actually, I'm reading about WebGL right now, and it appears to me that it should be very easy to support in Threepenny. While the communication between browser and server is comparatively slow, most of the hard work is done in the shading language anyway. The browser retrieves shading code from a `script` tag. It's straightforward to create such a tag in Threepenny, populate it, and make a few JavaScript FFI calls to start the rendering process. I currently have no plans to add WebGL support myself, but all the ingredients are in place. (Maybe wait until threepenny-0.4 , as I'm currently simplifying the FFI a bit.) PS: Conal, if you want to see whether the Threepenny + WebGL route is viable for you, it's probably a good idea to do a quick test in plain HTML + JS first, to see whether performance is good enough for your purpose. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com

Sven Panne

5 Oct 5 Oct

2:55 p.m.

New subject: Poll & plea: State of GUI & graphics libraries in Haskell

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.

Heinrich Apfelmus

6 Oct 6 Oct

4:47 a.m.

New subject: Poll & plea: State of GUI & graphics libraries in Haskell

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

Luis Cabellos

27 Sep 27 Sep

5:18 a.m.

New subject: Poll & plea: State of GUI & graphics libraries in Haskell

However, I would prefer to have two different types of libraries in haskell: For graphics, something like SFML or SDL, no GUI implicit. but with good/modern OpenGL. Maybe we won't need a direct binding, but rethinking who should be done a SDL-like library in Haskell. Yep, FRP is cool, but need clever people. Whenever I try to do a pet-game with that.. I always come back to C++. And for GUI, I had good feeling of gtk bindings in the past. Luis On Fri, Sep 27, 2013 at 5:32 AM, Conal Elliott 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

Oliver Charles

5:35 a.m.

New subject: Poll & plea: State of GUI & graphics libraries in Haskell

On 09/27/2013 04:32 AM, Conal Elliott wrote:

...

I'm polling to see whether there are will and expertise to reboot graphics and GUIs work in Haskell. I miss working on functional graphics and GUIs in Haskell, as I've been blocked for several years (eight?) due to the absence of low-level foundation libraries having the following properties:

* cross-platform, * easily buildable, * GHCi-friendly, and * OpenGL-compatible.

The last several times I tried Gtk2hs, I was unable to compile it on my Mac. Years ago when I was able to compile, the GUIs looked and interacted like a Linux app, which made them awkward and upleasant to use. wxHaskell (whose API and visual appearance I prefered) has for years been incompatible with GHCi, in that the second time I open a top-level window, the host process (GHCi) dies abruptly. Since my GUI & graphics programs are often one-liners, and I tend to experiment a lot, using a full compilation greatly thwarts my flow. For many years, I've thought that the situation would eventually improve, since I'm far from the only person who wants GUIs or graphics from Haskell.

We are working on bindings to SDL 2 at the moment - https://github.com/Lemmih/hsSDL2. They are currently usable for most 'stock' work - drawing things, doing interaction, window management, etc. However, I'm afraid SDL bindings don't really solve what you want in terms of a GUI programming. SDL2 at least gives you a sane cross platform way to create a window with an OpenGL context, and to draw things using hardware acceleration. If you actually need widgets, then SDL probably won't help here. - ocharles

Jason Dagit

1:36 p.m.

New subject: Poll & plea: State of GUI & graphics libraries in Haskell

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

Henk-Jan van Tuyl

4:39 p.m.

New subject: Poll & plea: State of GUI & graphics libraries in Haskell

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

Rustom Mody

28 Sep 28 Sep

8:13 a.m.

New subject: Poll & plea: State of GUI & graphics libraries in Haskell

...

I'm polling to see whether there are will and expertise to reboot graphics and GUIs work in Haskell. I miss working on functional graphics and GUIs in Haskell, as I've been blocked for several years (eight?) due to the absence of low-level foundation libraries having the following properties:

[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

On Fri, Sep 27, 2013 at 9:02 AM, Conal Elliott wrote: 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

Ivan Perez

9:01 a.m.

New subject: Poll & plea: State of GUI & graphics libraries in Haskell

Hi Conal, hi café, I'm currently devoting most of my time to this and plan to continue doing so (in the form of a PhD and work via my company). I've been working on a thorough review of the current status and a comparative analysis (using a fairly demanding, well-known algorithm to compare several aspects of different frameworks, including performance, readability, etc.) I can't give deadlines wrt. when things will be published, but would be happy to keep in touch with other people who are interested in this area of FP. Regards Ivan On 27 September 2013 05:32, Conal Elliott 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

Paul Liu

30 Sep 30 Sep

2:18 a.m.

New subject: Poll & plea: State of GUI & graphics libraries in Haskell

Hi Conal, I wasn't able to make it to last Saturday's FARM track, but I think there was a good chance that Paul would have demonstrated his Euterpea music library, which includes a GUI interface (called MUI) written on top of GLFW. I wrote its initial implementation (around 2009?) with a monadic interface that let you wire together UI components with signals (I believe Dan later wrote an arrow interface, but I could be wrong). It was actually inspired by the ideas behind your Phooey UI library. It should be very easy to extract this part out as a standalone package if there is enough interest. The only issue with it (and all other UI libraries) is that it doesn't play nicely in GHCi. It used to work pretty well with GHC 7.2 and 7.4 on almost all platforms (Mac needs an extra hack), but GHC 7.6 broke Mac (and perhaps Windows too). GHC 7.8 supposedly should fix this problem. BTW, as also the author of the GLFW library on HackageDB, I've done barely minimal to keep this Haskell binding afloat. I'm actually leaning towards GLFW-b library, which is better maintained, and provides similar binding for GLFW C library but with a saner interface (no dependency on the OpenGL library, for example). If you don't need the two extra things that GLFW does (choice of either dynamic or static linking to GLFW C, and an embedded bitmap font), I suggest you try out GLFW-b if you are only looking for a think graphics layer with input+window+OpenGL. The only thing keeping GLFW-b from becoming a good foundation for a pure Haskell UI lib is IMHO the lack of a light-weight, cross-platform, and full-featured font rendering solution. I believe many other libraries (including Diagram) are having the same problem. On Thu, Sep 26, 2013 at 8:32 PM, Conal Elliott 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

Sylvain HENRY

2 Oct 2 Oct

9:53 a.m.

New subject: Poll & plea: State of GUI & graphics libraries in Haskell

Hi, The best low-level foundation libraries that I know of are the Enlightenment Foundation Libraries (EFL) [1,2]. They are cross-platform : they support many backends (X11, OpenGL, framebuffer...) and are used on desktops and mobile devices (even to provide games on the French Free ISP box). It seems that they also work on exotic platforms such as Windows and Mac OS. They are fully written in C, hence are easy to build and to use from Haskell. Evas [3] is a stateful canvas onto which shapes and texts can be drawn. It supports OpenGL regions [4]. Ecore [5] is used to manage windows, timers, etc. especially with Ecore_Evas [6]. Edje allows you to clearly separate UI and the rest of the code. The same thing has been integrated into Qt with QML (and was present in Delphi decades ago ;)). It makes it easy to create animated UI, etc. Finally, Elementary is a standard widget toolkit based on Edje, Evas and Ecore. The good news is that I have been working on an Haskell binding for the EFL [7]. The bad news is that it is not complete. Evas, Ecore and Ecore_Evas are partially done but need more polishing and testing. This simple example here [8] works well in GHCI (even better than when the program is compiled because I haven't yet figured out why the text is not displayed in this latter case...). I do not plan to write bindings for Edje and Elementary as I would prefer an Haskell DSL to replace Edje and a widget toolkit on top of it (another project seems to provide some bindings for Elementary [9]). If you want to use the EFL as a "working foundation", I can try to work a little bit more on the binding. Cheers Sylvain [1] http://en.wikipedia.org/wiki/Enlightenment_Foundation_Libraries [2] http://www.enlightenment.org/p.php?p=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

Sven Panne

5 Oct 5 Oct

3:04 p.m.

New subject: Poll & plea: State of GUI & graphics libraries in Haskell

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 gui@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.

Heinrich Apfelmus

6 Oct 6 Oct

4:40 a.m.

New subject: Poll & plea: State of GUI & graphics libraries in Haskell

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

4245

Age (days ago)

4254

Last active (days ago)

List overview

Download

27 comments

20 participants

participants (20)

aditya siram
Atze Dijkstra
Carter Schonwald
Conal Elliott
Conrad Parker
Heinrich Apfelmus
Henk-Jan van Tuyl
Ivan Perez
Jason Dagit
John Lato
KC
Keshav Kini
Luis Cabellos
Oliver Charles
Paul Liu
Robin KAY
Rustom Mody
Sven Panne
Sylvain HENRY
Tikhon Jelvis