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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
41 messages Options
123
Reply | Threaded
Open this post in threaded view
|

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

Conal Elliott
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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

aditya siram-2
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 <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
KC
Reply | Threaded
Open this post in threaded view
|

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

KC
In reply to this post by Conal Elliott
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 <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe




--
--
Regards,
KC

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

Conrad Parker
In reply to this post by Conal Elliott
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 <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

John Lato-2
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

Carter Schonwald
In reply to this post by Conal Elliott
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 <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

Keshav Kini
In reply to this post by John Lato-2
John Lato <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

Heinrich Apfelmus
In reply to this post by Conal Elliott
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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: 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" <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

Luis Cabellos-2
In reply to this post by Conal Elliott
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 <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

Heinrich Apfelmus
In reply to this post by Tikhon Jelvis
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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

Oliver Charles-3
In reply to this post by Conal Elliott
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


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

signature.asc (501 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Robin KAY
In reply to this post by Keshav Kini
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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

Keshav Kini
Robin KAY <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

Jason Dagit-3
In reply to this post by Conal Elliott



On Thu, Sep 26, 2013 at 8:32 PM, Conal Elliott <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

Henk-Jan van Tuyl
In reply to this post by Conal Elliott
On Fri, 27 Sep 2013 05:32:18 +0200, Conal Elliott <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

Rustom Mody
In reply to this post by Conal Elliott
On Fri, Sep 27, 2013 at 9:02 AM, Conal Elliott <[hidden email]> 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

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

Ivan Perez-2
In reply to this post by Conal Elliott
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 <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

Paul Liu
In reply to this post by Conal Elliott
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 <[hidden email]> 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
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



--
Regards,
Paul Liu
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

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

Conal Elliott
In reply to this post by Conrad Parker
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe




_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
123