Interesting. How are the aesthetics? Can you point me to screen shots? It'd be a lot of work, but one cool project would be to create *beautiful* GUI elements using OpenGL programmable shaders. Given the speed of GPUs, we could afford to put a lot into visual details. A complementary project is designing a semantically precise and elegant ("denotative"/"genuinely functional" to use Peter Landin's terms) GUI DSEL that would be simpler and more powerful than the conventional OO-inspired libraries we have so much trouble getting to work in Haskell. I've thought about this sort of thing on and off for a very long time and would be happy to be involved if others are interested also. Together, these two efforts would yield an approach to GUIs that is beautiful inside and out. -- Conal On Wed, Oct 2, 2013 at 1:21 PM, Paul Liu wrote:

No. GLFW does not give you any UI elements, just basic windowing and input handling.

Euterpea has a UI layer on top of GLFW that provides text boxes and sliders, etc, entirely written in Haskell.

...

Hi Paul. Is there a way to use GLFW with GUI elements other than OpenGL display windows, e.g., text boxes and sliders? -- Conal

On Tue, Oct 1, 2013 at 11:23 PM, Paul Liu wrote:

...

Thanks. I've just built GHC HEAD on Mac OS X Lion, and tested by installing libraries with --enable-shared and loading a GLFW program into GHCi. Using ghci -fno-ghci-sandbox, everything works great including closing and restarting GL window multiple times. Can't wait for the official release of GHC 7.8!

On Tue, Oct 1, 2013 at 12:09 PM, Carter Schonwald wrote:

...

thats the linker bug.

the glfw stuff has been tested on ghc HEAD / 7.7 by folks on #haskell-game in recent memory. GHCI + foreign libs should work fine now (modulo thread local storage related thing).

the historical element doesn't matter any more.

To the best of my knowledge, all such issues should be gone. Anyone

who

...

...

cares about making sure GHCI+ gui libs play nice, PLEASE test with HEAD.

the better this issue is properly tested (which i believe it has been), the more we can actually prevent it from happening. This requires people to test with HEAD GHCi now, rather than doing archaeology.

anyone who cares, please play with GHCI in HEAD. If your lib doesn't work with ghci, please report a bug. It would be a new bug because it wont' be the previous reasons it hasnt' worked.

tl;dr to the best of my knowledge this issue is resolved in HEAD. Test HEAD. Help us make sure it stays resolved by testing HEAD.

thanks -Carter

On Tue, Oct 1, 2013 at 1:20 PM, Paul Liu wrote:

...

I reported a problem with statically linked GLFW library on Mac OS X Lion in this thread:

http://www.haskell.org/pipermail/haskell-cafe/2012-January/097355.html

...

I do not know why this is broken on Mac OS X Lion, but not on Linux

or

...

Windows. There was an EnableGUI hack for GHC 7.2 (and previous versions) and OS X version before Lion, but it no longer works. So I'm not sure if it is OS X Lion, or GLFW, or GHC, or a combination of

...

...

...

...

that caused this problem.

Regards, Paul Liu

On Tue, Oct 1, 2013 at 7:04 AM, Carter Schonwald wrote:

...

Hey simon, the two issues that have recurrently bit ghci interaction with foreign GUI libs are 1) the ghci linker. This is fixed in head by now having ghci use

...

...

...

...

...

system linker 2) some GUI libs require thread local state, and ghci has a flag for that 3) I'm not aware of anyone reporting newly broken libs wrt GUI bindings when 7.6 rolled out. The only fix that's relevant to 7.8 is the dylinker bit, but that would have been a problem historically too.

I believe a number of folks in #haskell-game have recently tested point one. (Though I should ask to double check)

At the very least, I'm not aware of hearing of such a 7.6 specific ghci breakage before.

On Tuesday, October 1, 2013, Simon Peyton-Jones wrote: > > Dear GHC devs > > > > See below (in red). I do not know the details of this, but it > sounds > like > a pretty serious problem, and it used to work. Is whatever-it-is > confirmed > fixed in 7.8? Do we have a test that’ll trip if it breaks again? > (I’m > guessing that the latter might be hard.) > > > > Thanks > > > > Simon > > > > -----Original Message----- > From: Haskell-Cafe [mailto:haskell-cafe-bounces@haskell.org] On > Behalf > Of > Paul Liu > Sent: 30 September 2013 07:18 > To: Conal Elliott > Cc: Haskell Cafe > Subject: Re: [Haskell-cafe] Poll & plea: State of GUI & graphics > libraries > in Haskell > > > > Hi Conal, > > > > I wasn't able to make it to last Saturday's FARM track, but I

...

...

...

...

...

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

On Wed, Oct 2, 2013 at 8:40 AM, Conal Elliott wrote: them the think properties:

...

...

...

...

...

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

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

-- Regards, Paul Liu

-- Regards, Paul Liu _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

-- Regards, Paul Liu

Hi guys, I have been willing to have a nice GUI DSEL with good aesthetics for a while. I think the hardest part wouldn't be the API, but really what library we use underneath so that it's cross-platform and easy to install for everyone. But I would love for something like that to happen and am very interested in this. Note that people from #haskell-game are experimenting a bit (I think it's mostly Jake McArthur's work for now), see the brainstorming (ideas) and graphics (partial impl) repositories at [1]. [1]: https://github.com/haskell-game On Thu, Oct 3, 2013 at 12:28 AM, Conal Elliott wrote:

Interesting. How are the aesthetics? Can you point me to screen shots?

It'd be a lot of work, but one cool project would be to create *beautiful* GUI elements using OpenGL programmable shaders. Given the speed of GPUs, we could afford to put a lot into visual details.

A complementary project is designing a semantically precise and elegant ("denotative"/"genuinely functional" to use Peter Landin's terms) GUI DSEL that would be simpler and more powerful than the conventional OO-inspired libraries we have so much trouble getting to work in Haskell. I've thought about this sort of thing on and off for a very long time and would be happy to be involved if others are interested also.

Together, these two efforts would yield an approach to GUIs that is beautiful inside and out.

-- Conal

On Wed, Oct 2, 2013 at 1:21 PM, Paul Liu wrote:

...

No. GLFW does not give you any UI elements, just basic windowing and input handling.

Euterpea has a UI layer on top of GLFW that provides text boxes and sliders, etc, entirely written in Haskell.

...

Hi Paul. Is there a way to use GLFW with GUI elements other than OpenGL display windows, e.g., text boxes and sliders? -- Conal

On Tue, Oct 1, 2013 at 11:23 PM, Paul Liu wrote:

...

Thanks. I've just built GHC HEAD on Mac OS X Lion, and tested by installing libraries with --enable-shared and loading a GLFW program into GHCi. Using ghci -fno-ghci-sandbox, everything works great including closing and restarting GL window multiple times. Can't wait for the official release of GHC 7.8!

On Tue, Oct 1, 2013 at 12:09 PM, Carter Schonwald wrote:

...

thats the linker bug.

the glfw stuff has been tested on ghc HEAD / 7.7 by folks on #haskell-game in recent memory. GHCI + foreign libs should work fine now (modulo thread local storage related thing).

the historical element doesn't matter any more.

To the best of my knowledge, all such issues should be gone. Anyone

who

...

...

cares about making sure GHCI+ gui libs play nice, PLEASE test with HEAD.

the better this issue is properly tested (which i believe it has been), the more we can actually prevent it from happening. This requires people to test with HEAD GHCi now, rather than doing archaeology.

anyone who cares, please play with GHCI in HEAD. If your lib doesn't work with ghci, please report a bug. It would be a new bug because it wont' be the previous reasons it hasnt' worked.

tl;dr to the best of my knowledge this issue is resolved in HEAD. Test HEAD. Help us make sure it stays resolved by testing HEAD.

thanks -Carter

On Tue, Oct 1, 2013 at 1:20 PM, Paul Liu wrote:

...

I reported a problem with statically linked GLFW library on Mac OS X Lion in this thread:

http://www.haskell.org/pipermail/haskell-cafe/2012-January/097355.html

...

I do not know why this is broken on Mac OS X Lion, but not on Linux

or

...

Windows. There was an EnableGUI hack for GHC 7.2 (and previous versions) and OS X version before Lion, but it no longer works. So I'm not sure if it is OS X Lion, or GLFW, or GHC, or a combination of

...

...

...

...

that caused this problem.

Regards, Paul Liu

On Tue, Oct 1, 2013 at 7:04 AM, Carter Schonwald wrote: > Hey simon, the two issues that have recurrently bit ghci interaction > with > foreign GUI libs are > 1) the ghci linker. This is fixed in head by now having ghci use

...

...

...

...

> system > linker > 2) some GUI libs require thread local state, and ghci has a flag for > that > 3) I'm not aware of anyone reporting newly broken libs wrt GUI > bindings > when 7.6 rolled out. The only fix that's relevant to 7.8 is the > dylinker > bit, but that would have been a problem historically too. > > I believe a number of folks in #haskell-game have recently tested > point > one. > (Though I should ask to double check) > > At the very least, I'm not aware of hearing of such a 7.6 specific > ghci > breakage before. > > > On Tuesday, October 1, 2013, Simon Peyton-Jones wrote: >> >> Dear GHC devs >> >> >> >> See below (in red). I do not know the details of this, but it >> sounds >> like >> a pretty serious problem, and it used to work. Is whatever-it-is >> confirmed >> fixed in 7.8? Do we have a test that’ll trip if it breaks again? >> (I’m >> guessing that the latter might be hard.) >> >> >> >> Thanks >> >> >> >> Simon >> >> >> >> -----Original Message----- >> From: Haskell-Cafe [mailto:haskell-cafe-bounces@haskell.org] On >> Behalf >> Of >> Paul Liu >> Sent: 30 September 2013 07:18 >> To: Conal Elliott >> Cc: Haskell Cafe >> Subject: Re: [Haskell-cafe] Poll & plea: State of GUI & graphics >> libraries >> in Haskell >> >> >> >> Hi Conal, >> >> >> >> I wasn't able to make it to last Saturday's FARM track, but I

...

...

...

...

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

On Wed, Oct 2, 2013 at 8:40 AM, Conal Elliott wrote: them the think properties:

...

...

...

...

>> >> > >> >> > * cross-platform, >> >> > * easily buildable, >> >> > * GHCi-friendly, and >> >> > * OpenGL-compatible. >> >> > >> >> > The last several times I tried Gtk2hs, I was unable to compile it >> > on >> > my >> > Mac. >> >> > Years ago when I was able to compile, the GUIs looked and >> > interacted >> > like a >> >> > Linux app, which made them awkward and upleasant to use. wxHaskell >> > (whose >> >> > API and visual appearance I prefered) has for years been >> > incompatible >> > with >> >> > GHCi, in that the second time I open a top-level window, the host >> > process >> >> > (GHCi) dies abruptly. Since my GUI & graphics programs are often >> > one-liners, >> >> > and I tend to experiment a lot, using a full compilation greatly >> > thwarts >> > my >> >> > flow. For many years, I've thought that the situation would >> > eventually >> >> > improve, since I'm far from the only person who wants GUIs or >> > graphics >> > from >> >> > Haskell. >> >> > >> >> > About three years ago, I built a modern replacement of my old Pan >> > and >> >> > V > > > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs >

-- Regards, Paul Liu

-- Regards, Paul Liu _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

-- Regards, Paul Liu

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

-- Alp Mestanogullari

Yes, sorry, why I brought up haskell-game wasn't clear. I meant to say there are already quite a few people willing to improve the situation of graphics programming in Haskell (may it be GUI, games, visualization, ...). And I think we should definitely talk to each other and try to come up with something good and that we would be proud of using, and that fits with the kind of composability and simplicity we can get with libraries from other domains. I just consider haskell-game a first step in that direction. On Fri, Oct 4, 2013 at 5:23 PM, Jake McArthur wrote:

I don't think I would quite say haskell-game is quite relevant. For that matter, the implementation on GitHub is not very good. It's too complicated to scale and too specialized. I've been starting a fresh implementation, since I learned a lot about what I really want to do writing that, but it is not public yet.

That said, I think our efforts on haskell-game are definitely complementary with efforts to improve GUI programming with Haskell, and we should collaborate where it makes sense.

On Fri, Oct 4, 2013 at 11:19 AM, Alp Mestanogullari wrote:

...

Hi guys,

I have been willing to have a nice GUI DSEL with good aesthetics for a while. I think the hardest part wouldn't be the API, but really what library we use underneath so that it's cross-platform and easy to install for everyone. But I would love for something like that to happen and am very interested in this.

Note that people from #haskell-game are experimenting a bit (I think it's mostly Jake McArthur's work for now), see the brainstorming (ideas) and graphics (partial impl) repositories at [1].

[1]: https://github.com/haskell-game

On Thu, Oct 3, 2013 at 12:28 AM, Conal Elliott wrote:

...

Interesting. How are the aesthetics? Can you point me to screen shots?

It'd be a lot of work, but one cool project would be to create *beautiful* GUI elements using OpenGL programmable shaders. Given the speed of GPUs, we could afford to put a lot into visual details.

A complementary project is designing a semantically precise and elegant ("denotative"/"genuinely functional" to use Peter Landin's terms) GUI DSEL that would be simpler and more powerful than the conventional OO-inspired libraries we have so much trouble getting to work in Haskell. I've thought about this sort of thing on and off for a very long time and would be happy to be involved if others are interested also.

Together, these two efforts would yield an approach to GUIs that is beautiful inside and out.

-- Conal

On Wed, Oct 2, 2013 at 1:21 PM, Paul Liu wrote:

...

No. GLFW does not give you any UI elements, just basic windowing and input handling.

Euterpea has a UI layer on top of GLFW that provides text boxes and sliders, etc, entirely written in Haskell.

...

Hi Paul. Is there a way to use GLFW with GUI elements other than OpenGL display windows, e.g., text boxes and sliders? -- Conal

On Tue, Oct 1, 2013 at 11:23 PM, Paul Liu wrote:

...

Thanks. I've just built GHC HEAD on Mac OS X Lion, and tested by installing libraries with --enable-shared and loading a GLFW program into GHCi. Using ghci -fno-ghci-sandbox, everything works great including closing and restarting GL window multiple times. Can't wait for the official release of GHC 7.8!

On Tue, Oct 1, 2013 at 12:09 PM, Carter Schonwald wrote: > thats the linker bug. > > the glfw stuff has been tested on ghc HEAD / 7.7 by folks on > #haskell-game > in recent memory. GHCI + foreign libs should work fine now (modulo > thread > local storage related thing). > > the historical element doesn't matter any more. > > To the best of my knowledge, all such issues should be gone.

Anyone who

...

> cares about making sure GHCI+ gui libs play nice, PLEASE test with HEAD. > > the better this issue is properly tested (which i believe it has been), > the > more we can actually prevent it from happening. This requires

...

...

> test > with HEAD GHCi now, rather than doing archaeology. > > anyone who cares, please play with GHCI in HEAD. If your lib doesn't > work > with ghci, please report a bug. It would be a new bug because it wont' > be > the previous reasons it hasnt' worked. > > > tl;dr to the best of my knowledge this issue is resolved in HEAD. Test > HEAD. > Help us make sure it stays resolved by testing HEAD. > > thanks > -Carter > > > > > On Tue, Oct 1, 2013 at 1:20 PM, Paul Liu wrote: >> >> I reported a problem with statically linked GLFW library on Mac OS X >> Lion in this thread: >> >> http://www.haskell.org/pipermail/haskell-cafe/2012-January/097355.html >> >> I do not know why this is broken on Mac OS X Lion, but not on Linux or >> Windows. There was an EnableGUI hack for GHC 7.2 (and previous >> versions) and OS X version before Lion, but it no longer works. So I'm >> not sure if it is OS X Lion, or GLFW, or GHC, or a combination of

...

...

>> that caused this problem. >> >> Regards, >> Paul Liu >> >> On Tue, Oct 1, 2013 at 7:04 AM, Carter Schonwald >> wrote: >> > Hey simon, the two issues that have recurrently bit ghci interaction >> > with >> > foreign GUI libs are >> > 1) the ghci linker. This is fixed in head by now having ghci use the >> > system >> > linker >> > 2) some GUI libs require thread local state, and ghci has a flag for >> > that >> > 3) I'm not aware of anyone reporting newly broken libs wrt GUI >> > bindings >> > when 7.6 rolled out. The only fix that's relevant to 7.8 is the >> > dylinker >> > bit, but that would have been a problem historically too. >> > >> > I believe a number of folks in #haskell-game have recently tested >> > point >> > one. >> > (Though I should ask to double check) >> > >> > At the very least, I'm not aware of hearing of such a 7.6 specific >> > ghci >> > breakage before. >> > >> > >> > On Tuesday, October 1, 2013, Simon Peyton-Jones wrote: >> >> >> >> Dear GHC devs >> >> >> >> >> >> >> >> See below (in red). I do not know the details of this, but it >> >> sounds >> >> like >> >> a pretty serious problem, and it used to work. Is whatever-it-is >> >> confirmed >> >> fixed in 7.8? Do we have a test that’ll trip if it breaks again? >> >> (I’m >> >> guessing that the latter might be hard.) >> >> >> >> >> >> >> >> Thanks >> >> >> >> >> >> >> >> Simon >> >> >> >> >> >> >> >> -----Original Message----- >> >> From: Haskell-Cafe [mailto:haskell-cafe-bounces@haskell.org] On >> >> Behalf >> >> Of >> >> Paul Liu >> >> Sent: 30 September 2013 07:18 >> >> To: Conal Elliott >> >> Cc: Haskell Cafe >> >> Subject: Re: [Haskell-cafe] Poll & plea: State of GUI & graphics >> >> libraries >> >> in Haskell >> >> >> >> >> >> >> >> Hi Conal, >> >> >> >> >> >> >> >> I wasn't able to make it to last Saturday's FARM track, but I

...

...

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

...

...

>> >> >> >> 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 < conal@conal.net> >> >> wrote: >> >> >> >> > I'm polling to see whether there are will and expertise to reboot >> >> > graphics >> >> >> >> > and GUIs work in Haskell. I miss working on functional graphics >> >> > and >> >> > GUIs >> >> > in >> >> >> >> > Haskell, as I've been blocked for several years (eight?) due to >> >> > the >> >> > absence >> >> >> >> > of low-level foundation libraries having the following

...

...

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

On Wed, Oct 2, 2013 at 8:40 AM, Conal Elliott wrote: people to them think this properties: old Pan

...

...

>> >> > and >> >> >> >> > V >> > >> > >> > _______________________________________________ >> > ghc-devs mailing list >> > ghc-devs@haskell.org >> > http://www.haskell.org/mailman/listinfo/ghc-devs >> > >> >> >> >> -- >> Regards, >> Paul Liu > >

-- Regards, Paul Liu _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

-- Regards, Paul Liu

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

-- Alp Mestanogullari

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

-- Alp Mestanogullari

If these said libraries let us write a good API on top, then perfect! The problem is to actually pick the ones fulfilling our needs I think, all the major candidatures have pretty serious drawbacks, AFAIK. On Sat, Oct 5, 2013 at 12:36 AM, Robin KAY wrote:

Dear Alp,

Alp Mestanogullari wrote: [snip]

I have been willing to have a nice GUI DSEL with good aesthetics for a

...

while. I think the hardest part wouldn't be the API, but really what library we use underneath so that it's cross-platform and easy to install for everyone. But I would love for something like that to happen and am very interested in this.

Herein lies, for my purposes, the downfall of attempts to build GUI tool-kits on top of a blank canvas. From the perspective of binding to the platform, getting the basic functionality of a cross-platform GLUT or SDL equivalent isn't terribly difficult. You can layer your own widget system on top but even if you don't care about native look and feel (and I don't particularly), there are still three big functionality hurdles in my mind to building serious applications:-

i) Proper text rendering is more difficult than placing one glyph after another on a line. You need to bind to each platform's text rendering engine: Pango/others, Uniscribe, and Core Text. ii) Proper text input is more difficult than listening for key press and release events. You need to bind to the each platform's input method system: XIM/IBus/others, IMM, and NSTextInputClient. iii) Proper accessibility is just difficult.

There are plenty of applications where that doesn't matter and there are lots of attractive things about a pure Haskell implementation with beautiful high-level API. However, from my perspective, there are also attractions to outsourcing as much of that work as possible to existing libraries on the other side of the FFI even though that seems to bring us down to lower-level.

Regards,

-- Robin KAY

______________________________**_________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://www.haskell.org/mailman/listinfo/haskell-cafe

-- Alp Mestanogullari