Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
, but requiring lots of hacking to get it all compiling. Any recent news? - Conal On Mon, May 23, 2011 at 2:33 AM, John Lato jwl...@gmail.com wrote: Message: 17 Date: Fri, 20 May 2011 15:59:51 -0700 From: Evan Laforge qdun...@gmail.com Subject: Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics To: Erik Hesselink hessel...@gmail.com Cc: haskell-cafe@haskell.org Message-ID: BANLkTi=74mm6ortu2e192jtoot9g49f...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Note that it is supposed to be possible to build gtk2hs with gtk+osx, which will not use X11 but use the native OS X GUI. I've not been able to get this to work, but it's been a while since I tried. The Haskell wiki mentions it doesn't support Glade, but does support Cairo. If this were to work, gtk2hs would be a serious option as well. I've tried this 3 or 4 times, and failed every time. It's crazy complicated. I used to use this combination regularly. IME the difficulties are primarily with getting a working gtk+osx build. Once that was accomplished, gtk2hs was a straightforward install, provided you build from the src repo with the -quartz flag. Recently I've switched to using macports gtk2 with the quartz, no-x11 variant, which also uses native cocoa. This is much more reliable than gtk+osx. I don't know if it supports Glade though. My biggest problem with wx is that there's no support for building 64-bit wx applications on OS X. If that were fixed I might prefer it. John Lato ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
fltk definitely has some good points, but I've always found it hideously ugly. Of course the default gtk on osx is ugly too, but some of the available themes are nice. However, getting gtk with OpenGL on osx was fairly easy. Everything worked out of the box except gtkglext (Haskell package). I've submitted some patches for that which hopefully will be applied to the repo soon. This is what I used: git darcs ghc-7.0.3 (self-compiled) cabal-install macports gtk2 +no_x11 +quartz macports gtkglext +no_x11 +quartz gtk2hs from source gtkglext (Haskell) from source I use a self-compiled ghc, but this should work with any ghc. Mixing ghc and macports can cause problems with libiconv, but the solutions are pretty well-known. Since I compile ghc, I configure it to use macports's libiconv so there aren't any conflicts. sudo port install gtkglext +no_x11 +quartz (wait a while...) darcs get --lazy http://code.haskell.org/gtk2hs cd gtk cabal install gtk2hs-buildtools chmod +x bootstrap.sh ./bootstrap.sh -fhave-quartz-gtk (wait a while...) cd .. darcs get --lazy http://code.haskell.org/gtkglext cd gtkglext darcs apply gtkglext.dpatch cabal install Until the source tree gets patched, you'll have to manually apply the patch bundle. If you want to avoid macports, it should be possible to use gtk-osx and gtkglext from source instead. However, I've found gtk-osx to be unstable and quite difficult to build in the past, so I'd strongly recommend macports, at least for now. The source install of gtkglext works just fine and can be used with macports gtk2 (I tested this). Since this path already uses macports there's not much benefit though. Cheers, John L On Wed, May 25, 2011 at 9:07 PM, Evan Laforge qdun...@gmail.com wrote: fltk supports OpenGL on windows, X11, and OS X, though I've never used it. The thing it doesn't have is a haskell binding, but as I mentioned I just bind whatever I need when I need it and since I don't need much it's easy. Dunno if this applies in your case though. Maybe it's my NIH, but I like to start with something too simple and add what I need rather than start with something that has more than I need and try to get it working. On Wed, May 25, 2011 at 11:58 AM, Conal Elliott co...@conal.net wrote: Thanks, John. Encouraging bit of news. Please do let us know what you learn when you try. - Conal On Tue, May 24, 2011 at 1:28 AM, John Lato jwl...@gmail.com wrote: You can use gtkglext to get OpenGL support. With the official release of gtkglext-1.2.0 there's a bit of hacking involved (that was probably me you're referring to), but it looks like the repo head has native Quartz. With any luck, you just need to build gtkglext from the repo, then the gtkglext package. I might have some time to try this later today; I'll report back if I get results. John Lato On Tue, May 24, 2011 at 6:01 AM, Conal Elliott co...@conal.net wrote: Last I tried, there wasn't native support for OpenGL with gtk, and I need OpenGL. Then more recently, I heard of some progress in that area, but requiring lots of hacking to get it all compiling. Any recent news? - Conal On Mon, May 23, 2011 at 2:33 AM, John Lato jwl...@gmail.com wrote: Message: 17 Date: Fri, 20 May 2011 15:59:51 -0700 From: Evan Laforge qdun...@gmail.com Subject: Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics To: Erik Hesselink hessel...@gmail.com Cc: haskell-cafe@haskell.org Message-ID: BANLkTi=74mm6ortu2e192jtoot9g49f...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Note that it is supposed to be possible to build gtk2hs with gtk+osx, which will not use X11 but use the native OS X GUI. I've not been able to get this to work, but it's been a while since I tried. The Haskell wiki mentions it doesn't support Glade, but does support Cairo. If this were to work, gtk2hs would be a serious option as well. I've tried this 3 or 4 times, and failed every time. It's crazy complicated. I used to use this combination regularly. IME the difficulties are primarily with getting a working gtk+osx build. Once that was accomplished, gtk2hs was a straightforward install, provided you build from the src repo with the -quartz flag. Recently I've switched to using macports gtk2 with the quartz, no-x11 variant, which also uses native cocoa. This is much more reliable than gtk+osx. I don't know if it supports Glade though. My biggest problem with wx is that there's no support for building 64-bit wx applications on OS X. If that were fixed I might prefer it. John Lato ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
On Wed, 18 May 2011 20:01:48 -0700, wren ng thornton w...@freegeek.org wrote: 3. Using the web as Haskell's main method of non-command line (graphical) deployment seems to lose two of Haskell's most powerful features: its type safety, and its speed. I agree with these disagreements. Web apps have long been touted as a replacement for desktop apps. For certain specific kinds of domains people have been able to realize them sufficiently well as web apps. But I am still of the firm belief that there are numerous domains where browser-based UIs are wholly inappropriate. There are interesting scenarios where a browser is not required. I haven't worked with Snoyman's wai-handler-webkit which may be along these lines, but there's also https://developer.mozilla.org/en/xulrunner which provides the intriguing capability of an application that has (cross-platform) native-looking local windows but which can also interact via a (local or remote) browser. Clearly there's a gap between here and there, but part of that gap is the ability to simply and easily generate internal Javascript (to drive xulrunner) without actually programming in Javascript (it's just an API layer to the display, which is what I interpreted Jurriën Stutterheim's comments to be referring to). -- -KQ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
Thanks, John. Encouraging bit of news. Please do let us know what you learn when you try. - Conal On Tue, May 24, 2011 at 1:28 AM, John Lato jwl...@gmail.com wrote: You can use gtkglext to get OpenGL support. With the official release of gtkglext-1.2.0 there's a bit of hacking involved (that was probably me you're referring to), but it looks like the repo head has native Quartz. With any luck, you just need to build gtkglext from the repo, then the gtkglext package. I might have some time to try this later today; I'll report back if I get results. John Lato On Tue, May 24, 2011 at 6:01 AM, Conal Elliott co...@conal.net wrote: Last I tried, there wasn't native support for OpenGL with gtk, and I need OpenGL. Then more recently, I heard of some progress in that area, but requiring lots of hacking to get it all compiling. Any recent news? - Conal On Mon, May 23, 2011 at 2:33 AM, John Lato jwl...@gmail.com wrote: Message: 17 Date: Fri, 20 May 2011 15:59:51 -0700 From: Evan Laforge qdun...@gmail.com Subject: Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics To: Erik Hesselink hessel...@gmail.com Cc: haskell-cafe@haskell.org Message-ID: BANLkTi=74mm6ortu2e192jtoot9g49f...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Note that it is supposed to be possible to build gtk2hs with gtk+osx, which will not use X11 but use the native OS X GUI. I've not been able to get this to work, but it's been a while since I tried. The Haskell wiki mentions it doesn't support Glade, but does support Cairo. If this were to work, gtk2hs would be a serious option as well. I've tried this 3 or 4 times, and failed every time. It's crazy complicated. I used to use this combination regularly. IME the difficulties are primarily with getting a working gtk+osx build. Once that was accomplished, gtk2hs was a straightforward install, provided you build from the src repo with the -quartz flag. Recently I've switched to using macports gtk2 with the quartz, no-x11 variant, which also uses native cocoa. This is much more reliable than gtk+osx. I don't know if it supports Glade though. My biggest problem with wx is that there's no support for building 64-bit wx applications on OS X. If that were fixed I might prefer it. John Lato ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
fltk supports OpenGL on windows, X11, and OS X, though I've never used it. The thing it doesn't have is a haskell binding, but as I mentioned I just bind whatever I need when I need it and since I don't need much it's easy. Dunno if this applies in your case though. Maybe it's my NIH, but I like to start with something too simple and add what I need rather than start with something that has more than I need and try to get it working. On Wed, May 25, 2011 at 11:58 AM, Conal Elliott co...@conal.net wrote: Thanks, John. Encouraging bit of news. Please do let us know what you learn when you try. - Conal On Tue, May 24, 2011 at 1:28 AM, John Lato jwl...@gmail.com wrote: You can use gtkglext to get OpenGL support. With the official release of gtkglext-1.2.0 there's a bit of hacking involved (that was probably me you're referring to), but it looks like the repo head has native Quartz. With any luck, you just need to build gtkglext from the repo, then the gtkglext package. I might have some time to try this later today; I'll report back if I get results. John Lato On Tue, May 24, 2011 at 6:01 AM, Conal Elliott co...@conal.net wrote: Last I tried, there wasn't native support for OpenGL with gtk, and I need OpenGL. Then more recently, I heard of some progress in that area, but requiring lots of hacking to get it all compiling. Any recent news? - Conal On Mon, May 23, 2011 at 2:33 AM, John Lato jwl...@gmail.com wrote: Message: 17 Date: Fri, 20 May 2011 15:59:51 -0700 From: Evan Laforge qdun...@gmail.com Subject: Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics To: Erik Hesselink hessel...@gmail.com Cc: haskell-cafe@haskell.org Message-ID: BANLkTi=74mm6ortu2e192jtoot9g49f...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Note that it is supposed to be possible to build gtk2hs with gtk+osx, which will not use X11 but use the native OS X GUI. I've not been able to get this to work, but it's been a while since I tried. The Haskell wiki mentions it doesn't support Glade, but does support Cairo. If this were to work, gtk2hs would be a serious option as well. I've tried this 3 or 4 times, and failed every time. It's crazy complicated. I used to use this combination regularly. IME the difficulties are primarily with getting a working gtk+osx build. Once that was accomplished, gtk2hs was a straightforward install, provided you build from the src repo with the -quartz flag. Recently I've switched to using macports gtk2 with the quartz, no-x11 variant, which also uses native cocoa. This is much more reliable than gtk+osx. I don't know if it supports Glade though. My biggest problem with wx is that there's no support for building 64-bit wx applications on OS X. If that were fixed I might prefer it. John Lato ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
You can use gtkglext to get OpenGL support. With the official release of gtkglext-1.2.0 there's a bit of hacking involved (that was probably me you're referring to), but it looks like the repo head has native Quartz. With any luck, you just need to build gtkglext from the repo, then the gtkglext package. I might have some time to try this later today; I'll report back if I get results. John Lato On Tue, May 24, 2011 at 6:01 AM, Conal Elliott co...@conal.net wrote: Last I tried, there wasn't native support for OpenGL with gtk, and I need OpenGL. Then more recently, I heard of some progress in that area, but requiring lots of hacking to get it all compiling. Any recent news? - Conal On Mon, May 23, 2011 at 2:33 AM, John Lato jwl...@gmail.com wrote: Message: 17 Date: Fri, 20 May 2011 15:59:51 -0700 From: Evan Laforge qdun...@gmail.com Subject: Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics To: Erik Hesselink hessel...@gmail.com Cc: haskell-cafe@haskell.org Message-ID: BANLkTi=74mm6ortu2e192jtoot9g49f...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Note that it is supposed to be possible to build gtk2hs with gtk+osx, which will not use X11 but use the native OS X GUI. I've not been able to get this to work, but it's been a while since I tried. The Haskell wiki mentions it doesn't support Glade, but does support Cairo. If this were to work, gtk2hs would be a serious option as well. I've tried this 3 or 4 times, and failed every time. It's crazy complicated. I used to use this combination regularly. IME the difficulties are primarily with getting a working gtk+osx build. Once that was accomplished, gtk2hs was a straightforward install, provided you build from the src repo with the -quartz flag. Recently I've switched to using macports gtk2 with the quartz, no-x11 variant, which also uses native cocoa. This is much more reliable than gtk+osx. I don't know if it supports Glade though. My biggest problem with wx is that there's no support for building 64-bit wx applications on OS X. If that were fixed I might prefer it. John Lato ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
Message: 17 Date: Fri, 20 May 2011 15:59:51 -0700 From: Evan Laforge qdun...@gmail.com Subject: Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics To: Erik Hesselink hessel...@gmail.com Cc: haskell-cafe@haskell.org Message-ID: BANLkTi=74mm6ortu2e192jtoot9g49f...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Note that it is supposed to be possible to build gtk2hs with gtk+osx, which will not use X11 but use the native OS X GUI. I've not been able to get this to work, but it's been a while since I tried. The Haskell wiki mentions it doesn't support Glade, but does support Cairo. If this were to work, gtk2hs would be a serious option as well. I've tried this 3 or 4 times, and failed every time. It's crazy complicated. I used to use this combination regularly. IME the difficulties are primarily with getting a working gtk+osx build. Once that was accomplished, gtk2hs was a straightforward install, provided you build from the src repo with the -quartz flag. Recently I've switched to using macports gtk2 with the quartz, no-x11 variant, which also uses native cocoa. This is much more reliable than gtk+osx. I don't know if it supports Glade though. My biggest problem with wx is that there's no support for building 64-bit wx applications on OS X. If that were fixed I might prefer it. John Lato ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
Last I tried, there wasn't native support for OpenGL with gtk, and I need OpenGL. Then more recently, I heard of some progress in that area, but requiring lots of hacking to get it all compiling. Any recent news? - Conal On Mon, May 23, 2011 at 2:33 AM, John Lato jwl...@gmail.com wrote: Message: 17 Date: Fri, 20 May 2011 15:59:51 -0700 From: Evan Laforge qdun...@gmail.com Subject: Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics To: Erik Hesselink hessel...@gmail.com Cc: haskell-cafe@haskell.org Message-ID: BANLkTi=74mm6ortu2e192jtoot9g49f...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Note that it is supposed to be possible to build gtk2hs with gtk+osx, which will not use X11 but use the native OS X GUI. I've not been able to get this to work, but it's been a while since I tried. The Haskell wiki mentions it doesn't support Glade, but does support Cairo. If this were to work, gtk2hs would be a serious option as well. I've tried this 3 or 4 times, and failed every time. It's crazy complicated. I used to use this combination regularly. IME the difficulties are primarily with getting a working gtk+osx build. Once that was accomplished, gtk2hs was a straightforward install, provided you build from the src repo with the -quartz flag. Recently I've switched to using macports gtk2 with the quartz, no-x11 variant, which also uses native cocoa. This is much more reliable than gtk+osx. I don't know if it supports Glade though. My biggest problem with wx is that there's no support for building 64-bit wx applications on OS X. If that were fixed I might prefer it. John Lato ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
Jeremy O'Donoghue wrote: - What everyone would *really* like is a less 'imperative' style of GUI programming. It's true that wxHaskell, GtkHS and so on basically let you do type safe C programming. This *does* need the uber type hackers and Haskell experts, but work in this direction has been equally stifled by the fact that the GUI bindings like wxHaskell tend not to get enough love to fix issues they are seeing. The reactive-banana library is my attempt to work on that. http://apfelmus.nfshost.com/blog/2011/04/28-frp-banana-0-2.html Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
On 2011-05-20, Evan Laforge qdun...@gmail.com wrote: Note that it is supposed to be possible to build gtk2hs with gtk+osx, which will not use X11 but use the native OS X GUI. I've not been able to get this to work, but it's been a while since I tried. The Haskell wiki mentions it doesn't support Glade, but does support Cairo. If this were to work, gtk2hs would be a serious option as well. I've tried this 3 or 4 times, and failed every time. It's crazy complicated. A couple of months ago I succeeded in installing gtk2hs like this on a Snow Leopard MacBook Air and it seemed to work pretty well. It was indeed a fairly involved process but it seemed to work and, with a slightly modified ige-mac-integration, got nice mac-style menu bars etc. for my application. Unfortunately I'm travelling at the moment and don't have the mac with me and I'm a little hazy on the details but when I get back I'll try to write up my experience. Murray Campbell mur...@sonology.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
That's correct - I haven't yet got a stable solution for using ghci with wxHaskell - Jeremy On 18 May 2011 20:33, Conal Elliott co...@conal.net wrote: Last I heard, wx still had the problem of crashing its host the second time one opens a window (which is typical in ghci). And last I heard, Jeremy O'Donoghue (cc'd) was exploring solutions but had very little time to pursue them. - Conal On Wed, May 18, 2011 at 11:42 AM, Tom Murphy amin...@gmail.com wrote: My conclusion was that GLFW-b (on hackage) is the best we have right now. I think we could do even better than the C libraries out there by writing the GLUT/GLFW/etc implementation purely in Haskell. We already have x11 and gtk bindings for the linux support. We have win32 api bindings for windows support. What we are lacking is good low level support for OSX GUI programming. Once we have that it's not too much of a stretch to use cabal to glue it together into a cross platform library. I believe that's the right way to go for the long term. Improving GLFW-b is a good short-term route. Would it be possible to do it with wx? There would be a much larger potential developer pool, since it's cross-platform. (Not getting away from C libraries, but they're stable). And just to say it one more time, I can use all the help I can get. There are a lot of yaks to be shaved. My hope is that if we all shave one yak then we'll quickly have the libraries we need to do some serious graphics hacking in Haskell. We already have many good libraries for it, we just need to improve and polish a few key libraries. The momentum is here and a few people have already jumped in. Time to get on board! Count me as onboard; I'm just not sure which ship I'm on yet. Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
On 19 May 2011 14:01, Heinrich Apfelmus apfel...@quantentunnel.de wrote: Conal Elliott wrote: Last I heard, wx still had the problem of crashing its host the second time one opens a window (which is typical in ghci). And last I heard, Jeremy O'Donoghue (cc'd) was exploring solutions but had very little time to pursue them. - Conal Last I remember, the latest problem is that ghci is unable to link libstdc++. But the crash problem is probably still there. There are two separate problems: - ghci unable to link static libstdc++ (so doesn't work at all on Windows). Actually this should be fixed with ghc 7.0.2, but I have not yet verified (in the process of doing so now), as ghc now ships with libstdc++ as a dll. - wxWidgets static destructors are not called when application terminates, so second app run crashes (all platforms) Jeremy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
On 20 May 2011 02:48, Evan Laforge qdun...@gmail.com wrote: On Thu, May 19, 2011 at 5:32 PM, Felipe Almeida Lessa felipe.le...@gmail.com wrote: On Thu, May 19, 2011 at 9:23 PM, John Lask jvl...@hotmail.com wrote: A general problem with strategic response is they underestimate the effort required due to the long range horizon and the uncertainties involved. The efforts in building a cross-platform GUI are not to be underestimated. Otherwise nobody would have problems in using Gtk/Qt/Wx, all three well-developed by many hands. Maybe I'm underestimating, but from working with fltk it doesn't seem that bad. It seems very daurting if you look at giant toolkits like gtk, but the entire cocoa backend for fltk is just 3,500 lines of objective C++. It isn't hard (for the most part) but it is tedious. For most of the time I have been working on wxHaskell, the core issue has been getting the thing to build and install, repeatably, on machines with different OS versions, tools and the like. In the case of wxHaskell, the progression has been (approximately) - Older versions use a make based build system. This was very fragile when it came to supporting multiple platforms, although it had the benefit of being very flexible, and supporting some options we don't support now. Biggest problem was that every new user would spend hours fighting to get the thing to build (as would I if I hadn't looked at it for a while). - Move to a partial cabal/make system. This built the Haskell components using cabal and the C++ components using make. Still too fragile for most users, and didn't fulfill the itch to allow 'cabal install wx'. - Move to a fully cabalized system. This has essentially required us to build a C++ build system in custom Cabal build stanzas. Notice - nothing hard in any of the above, but not much fun either. It's mainly about dealing with obscure link errors and platform issues. Generally adding extra functions is the work of just a few minutes! Do it in the worlds best imperative language, implement only the widgets I need, and do it in a more high level and modern style, and omit stuff I don't like like DnD :), and it doesn't seem very scary to me. Hmm. I guess we will need to get the entire Haskell GUI world to agree on which functionality is 'useful' and/or 'liked'. You quickly find that the union of minimum 'essential' functionality is 'almost everything'. Even the 'simple' GUI features will turn out to involve many function calls. IMHO, if you want programs with native look feel on many platforms, separate internal code from the GUI code and make one GUI for Windows, another GUI using Gtk, another one using Qt and another one using Cocoa (example [1]). Even if your toolkit was perfect, platforms have different practices and cultures that should be accounted for. I like this approach too. I write the GUI in c++ and then export a medium level C API of only 10-20 functions and FFI it. I use fltk, but if I really cared about the GUI then I could write native backends for each platform. If you really want to put a lot of effort into the GUI and have it just right, I think it's the only option. Actually, toolkits like wx and Qt go to a lot of trouble to deal with most platform practices and cultures. While I agree in principle that writing the GUI directly in a platform toolkit will give the best results (at least aesthetically), it has its downsides. For example, to write a moderately complex GUI for a program supporting Windows, Mac and Linux would require me to put together GUIs in C# (Windows WPF, for example), C (Gtk) and Objective C. It is far from a trivial undertaking to learn enough of any of these to produce a GUI which is significantly better than wx would product out of the box, using the same source code for all platforms. However... if you are willing to make such an effort, it is absolutely going to produce better results than a cross-platform toolkit. Having said that, I believe that there is a 'market' for a GUI toolkit which is capable of producing good quality results - very close to native on all platforms - from one piece of source code. The problem, as I see it, is that: - Doing a cross-platform GUI library for Haskell based on one of the major libraries is somewhat tedious for the most part. No one will be able to brag about their awesome type hackery... - Proof is that wxHaskell is basically me, with specific contributions (some awesome) from others. I have the impression that GtkHS has a similarly small core team. - You need pretty good C or C++ and linker skills. Haskell skills are actually less important. - The size of the community means that fragmenting effort across multiple GUI platforms is a mistake. If there were 10 people each contributing significantly to wxHaskell, GtkHS and QtHaskell, we would have every reason to support them all.
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
On 5/20/11 8:35 AM, Jeremy O'Donoghue wrote: I would like to suggest, quite seriously, that the Haskell community try to come to a consensus about supporting a single Haskell GUI, with a view to distribution in the HP. Obviously my vote is for wxHaskell, but I'm quite prepared to loose the vote. Reason is that I think we need to concentrate some effort on getting one GUI binding to 'production' status, and I don't believe that on the current basis we will ever do this. From my perspective, only GtkHS and wxHaskell look like serious candidates with at least some history and maturity behind them. If you are going to rule out Qt, then the only good cross-platform option remaining is wx since Gtk is not fully native on OSX but instead uses X11 which results in an inferior user experience, and it would be a bad idea to have that be the standard that everyone associates with applications written in Haskell. Cheers, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
On Fri, May 20, 2011 at 20:39, Gregory Crosswhite gcr...@phys.washington.edu wrote: On 5/20/11 8:35 AM, Jeremy O'Donoghue wrote: I would like to suggest, quite seriously, that the Haskell community try to come to a consensus about supporting a single Haskell GUI, with a view to distribution in the HP. Obviously my vote is for wxHaskell, but I'm quite prepared to loose the vote. Reason is that I think we need to concentrate some effort on getting one GUI binding to 'production' status, and I don't believe that on the current basis we will ever do this. From my perspective, only GtkHS and wxHaskell look like serious candidates with at least some history and maturity behind them. If you are going to rule out Qt, then the only good cross-platform option remaining is wx since Gtk is not fully native on OSX but instead uses X11 which results in an inferior user experience, and it would be a bad idea to have that be the standard that everyone associates with applications written in Haskell. Note that it is supposed to be possible to build gtk2hs with gtk+osx, which will not use X11 but use the native OS X GUI. I've not been able to get this to work, but it's been a while since I tried. The Haskell wiki mentions it doesn't support Glade, but does support Cairo. If this were to work, gtk2hs would be a serious option as well. Erik ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
Note that it is supposed to be possible to build gtk2hs with gtk+osx, which will not use X11 but use the native OS X GUI. I've not been able to get this to work, but it's been a while since I tried. The Haskell wiki mentions it doesn't support Glade, but does support Cairo. If this were to work, gtk2hs would be a serious option as well. I've tried this 3 or 4 times, and failed every time. It's crazy complicated. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Status of Haskell + Mac + GUIs graphics
Hi, i am really happy about this lively discussion around Haskell (Mac) GUIs. I might hint to two other options: 1) Eclipse's SWT wraps the native platform's toolkits quite sucessfully. The platform-dependent bindings are mostly automatically generated, afaik. Some time ago i summarized my thoughts about extending SWT's infrastructure/code for Haskell here: http://www.reddit.com/r/haskell_proposals/comments/9w7nk/adjust_the_swt_binding_generators_for_haskell/ 2) Ruby's Shoes provides simple native wrappers as i've pointed out on Reddit: http://www.reddit.com/r/haskell/comments/he8pl/status_of_haskell_mac_guis_graphics/ Bye, Lenny ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
My conclusion was that GLFW-b (on hackage) is the best we have right now. I think we could do even better than the C libraries out there by writing the GLUT/GLFW/etc implementation purely in Haskell. We already have x11 and gtk bindings for the linux support. We have win32 api bindings for windows support. What we are lacking is good low level support for OSX GUI programming. Once we have that it's not too much of a stretch to use cabal to glue it together into a cross platform library. I believe that's the right way to go for the long term. Improving GLFW-b is a good short-term route. I agree with your approach. Although getting a window on screen really isn't much code, so I'd vote for going straight to a Haskell replacement for GLUT et al. And just to say it one more time, I can use all the help I can get. I don't have much time, but if someone started a github project for a Haskell GLUT replacement I could probably chip in here and there. Ta, Sam ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
Jason Dagit wrote: As you point out we also need better libraries for creating the OpenGL context. I wrote up my searches on that front here: http://blog.codersbase.com/2011/03/picking-gui-library-to-use-with-opengl.html My conclusion was that GLFW-b (on hackage) is the best we have right now. I think we could do even better than the C libraries out there by writing the GLUT/GLFW/etc implementation purely in Haskell. Not sure about that. I have looked at the GLFW source code, it's the cleanest C code I have ever seen and definitely worth contributing to. The thing with established cross-platform GUI toolkits is that they embed a lot of wisdom about platform quirks (Cocoa is particularly annoying) that you would have to solve again. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
Conal Elliott wrote: Last I heard, wx still had the problem of crashing its host the second time one opens a window (which is typical in ghci). And last I heard, Jeremy O'Donoghue (cc'd) was exploring solutions but had very little time to pursue them. - Conal Last I remember, the latest problem is that ghci is unable to link libstdc++. But the crash problem is probably still there. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
On 19/05/2011 10:31 PM, Heinrich Apfelmus wrote: my comments for what their worth: (1) wx and ghci: I successfully run wx in ghci (albeit) on windows. I take an alternative path to that proscribed by the current build process - I think principally so that I am able to run it in ghci, although I can not now recall the exact reason why I took the different route. The current build process links the haskell wxcore library against the wxwdigets libraries directly. Once upon a time, the wxlibraries were wrapped as a C (dll) library, and the haskell libraries linked against this. I choose this route, and have no problems loading wxwdigets applications in ghci (on windows) ... and using OpenGL with them. (2) on the question of GUI libraries in general. I remind readers that the discussion of a GUI for haskell is no new thing, (cf. GUI API Taskforce) http://www.haskell.org/pipermail/haskell/2001-September/007960.html http://comments.gmane.org/gmane.comp.lang.haskell.gui/7 ... and many more ... a lot of which has been said recently, has been said before (it does not make it less relevant, though) ... there are two very different responses, the tactical and the strategic, they generally have very different time frames and cost (effort) required. A tactical response might be to ensure that one of the (many) currently existing libraries (wxHaskell, qtHaskell, hs-fltk...) built and operated problem free on all platforms. Whereas, a strategic response might be to have a cross platform gui library binding to low level platform libraries (Win32, X11, Cocoa) Of course there are all sorts of variants in between. A general problem with strategic response is they underestimate the effort required due to the long range horizon and the uncertainties involved. if the question is what will provide me with the tools that I need today or tomorrow, which is the more efficacious response? Conal Elliott wrote: Last I heard, wx still had the problem of crashing its host the second time one opens a window (which is typical in ghci). And last I heard, Jeremy O'Donoghue (cc'd) was exploring solutions but had very little time to pursue them. - Conal Last I remember, the latest problem is that ghci is unable to link libstdc++. But the crash problem is probably still there. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
Do GUIs or interactive graphics in Haskell work a lot better on Windows and/or various Linux distro's? On Tue, May 17, 2011 at 4:24 PM, Conal Elliott co...@conal.net wrote: I still haven't found any way to do GUIs or interactive graphics in Haskell on a Mac that isn't plagued one or more of the following serious problems: * Incompatible with ghci, e.g., fails to make a window frame or kills the process the second time one opens a top-level window, * Goes through the X server, and so doesn't look or act like a Mac app, * Doesn't support OpenGL. A year or two ago, I put my Haskell GUI graphics work on hold while waiting hoping for a functioning pathway to open. So far I haven't heard of one. If anyone has found a solution, I'd love to hear! - Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- -- Regards, KC ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
On Thu, May 19, 2011 at 9:23 PM, John Lask jvl...@hotmail.com wrote: A general problem with strategic response is they underestimate the effort required due to the long range horizon and the uncertainties involved. The efforts in building a cross-platform GUI are not to be underestimated. Otherwise nobody would have problems in using Gtk/Qt/Wx, all three well-developed by many hands. IMHO, if you want programs with native look feel on many platforms, separate internal code from the GUI code and make one GUI for Windows, another GUI using Gtk, another one using Qt and another one using Cocoa (example [1]). Even if your toolkit was perfect, platforms have different practices and cultures that should be accounted for. Cheers =), [1] http://www.transmissionbt.com/ -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
On Thu, May 19, 2011 at 5:32 PM, Felipe Almeida Lessa felipe.le...@gmail.com wrote: On Thu, May 19, 2011 at 9:23 PM, John Lask jvl...@hotmail.com wrote: A general problem with strategic response is they underestimate the effort required due to the long range horizon and the uncertainties involved. The efforts in building a cross-platform GUI are not to be underestimated. Otherwise nobody would have problems in using Gtk/Qt/Wx, all three well-developed by many hands. Maybe I'm underestimating, but from working with fltk it doesn't seem that bad. It seems very daurting if you look at giant toolkits like gtk, but the entire cocoa backend for fltk is just 3,500 lines of objective C++. The entire library is about 100k lines (via wc) including headers, comments, doxygen, blank lines, etc. and I only use a fraction of that. Do it in the worlds best imperative language, implement only the widgets I need, and do it in a more high level and modern style, and omit stuff I don't like like DnD :), and it doesn't seem very scary to me. It's not going to have native look and feel since the OS level just provides drawing primitives (otherwise I think it would be a really complicated interface with lots of OS level differences), but it provides access to the underlying window pointer so you can add a native file chooser (as fltk does), etc. I think the main thing would be not trying to support all GUI features, just simple ones. If I had a lot of GUI enthusiasm and no other project I would be tempted to just try it. IMHO, if you want programs with native look feel on many platforms, separate internal code from the GUI code and make one GUI for Windows, another GUI using Gtk, another one using Qt and another one using Cocoa (example [1]). Even if your toolkit was perfect, platforms have different practices and cultures that should be accounted for. I like this approach too. I write the GUI in c++ and then export a medium level C API of only 10-20 functions and FFI it. I use fltk, but if I really cared about the GUI then I could write native backends for each platform. If you really want to put a lot of effort into the GUI and have it just right, I think it's the only option. However, we could still have a library that provided a standard for things like event types and event loop utilities. And I think for GUIs that don't have to be native and have fancy features, there is still a place for a simple cross platform GUI library. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
I still haven't found any way to do GUIs or interactive graphics in Haskell on a Mac that isn't plagued one or more of the following serious problems: * Incompatible with ghci, e.g., fails to make a window frame or kills the process the second time one opens a top-level window, * Goes through the X server, and so doesn't look or act like a Mac app, * Doesn't support OpenGL. If there doesn't currently exist something without these handicaps, that's a serious problem for the use of Haskell for developing end-user software. If we as a community want to be able to develop software for end-users (i.e. people who'll be thrown off by gtk widgets or x11 windows)*, then it would be a very good idea to focus our energies on one or two promising pre-existing libraries, and hammer them into completion. A roadmap for this could be worked on at Hac Phi? Just my 2¢, Tom *This, of course, would NOT be avoiding success at all costs. :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
A few weeks ago I set out to build a GUI app using wxHaskell. Long story short, we ditched the entire idea of a desktop GUI and went for a web application instead, because it was easier to develop a front-end for it and it was easier to style it. So here's my (perhaps slightly provoking) question: do we need to care at all about good GUI toolkits being available? Web applications, especially with an HTML 5 front-end, have become increasingly more powerful. If we can also find a good, standardized way to generate JS from our Haskell code, we're pretty much all set. Jurriën On 18 May, 2011, at 08:29 , Tom Murphy wrote: I still haven't found any way to do GUIs or interactive graphics in Haskell on a Mac that isn't plagued one or more of the following serious problems: * Incompatible with ghci, e.g., fails to make a window frame or kills the process the second time one opens a top-level window, * Goes through the X server, and so doesn't look or act like a Mac app, * Doesn't support OpenGL. If there doesn't currently exist something without these handicaps, that's a serious problem for the use of Haskell for developing end-user software. If we as a community want to be able to develop software for end-users (i.e. people who'll be thrown off by gtk widgets or x11 windows)*, then it would be a very good idea to focus our energies on one or two promising pre-existing libraries, and hammer them into completion. A roadmap for this could be worked on at Hac Phi? Just my 2¢, Tom *This, of course, would NOT be avoiding success at all costs. :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
Along the same lines, once or twice I've needed to create a desktop version of a web app, which is what I wrote wai-handler-webkit[1] for. It only really builds properly on Linux for now, but if the need arises I don't see any reason it wouldn't work for Mac/Windows as well. Michael [1] http://hackage.haskell.org/package/wai-handler-webkit 2011/5/18 Jurriën Stutterheim j.stutterh...@me.com: A few weeks ago I set out to build a GUI app using wxHaskell. Long story short, we ditched the entire idea of a desktop GUI and went for a web application instead, because it was easier to develop a front-end for it and it was easier to style it. So here's my (perhaps slightly provoking) question: do we need to care at all about good GUI toolkits being available? Web applications, especially with an HTML 5 front-end, have become increasingly more powerful. If we can also find a good, standardized way to generate JS from our Haskell code, we're pretty much all set. Jurriën On 18 May, 2011, at 08:29 , Tom Murphy wrote: I still haven't found any way to do GUIs or interactive graphics in Haskell on a Mac that isn't plagued one or more of the following serious problems: * Incompatible with ghci, e.g., fails to make a window frame or kills the process the second time one opens a top-level window, * Goes through the X server, and so doesn't look or act like a Mac app, * Doesn't support OpenGL. If there doesn't currently exist something without these handicaps, that's a serious problem for the use of Haskell for developing end-user software. If we as a community want to be able to develop software for end-users (i.e. people who'll be thrown off by gtk widgets or x11 windows)*, then it would be a very good idea to focus our energies on one or two promising pre-existing libraries, and hammer them into completion. A roadmap for this could be worked on at Hac Phi? Just my 2¢, Tom *This, of course, would NOT be avoiding success at all costs. :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
Conal Elliott wrote: I still haven't found any way to do GUIs or interactive graphics in Haskell on a Mac that isn't plagued one or more of the following serious problems: * Incompatible with ghci, e.g., fails to make a window frame or kills the process the second time one opens a top-level window, * Goes through the X server, and so doesn't look or act like a Mac app, * Doesn't support OpenGL. A year or two ago, I put my Haskell GUI graphics work on hold while waiting hoping for a functioning pathway to open. So far I haven't heard of one. If anyone has found a solution, I'd love to hear! I've asked a similar question on stackoverflow http://stackoverflow.com/questions/5868916/ and answered it myself. Basically, GLFW works (on my machine) as long as you don't call the GLFW.terminate function. The answer includes an example program that you can try out. It might be worth to include the extra hoops (EnableGUI) in the GLFW package. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
I have developed a GUI app using wxHaskell I develop using GHCi - invaluable I can run the application once form GHCi, and then a re-run crashes, but - usually after a run there is enough time to re-start GHCi while I tihnk about what needs fixing next - usually I can still run tests and queries from GHCi afterwards... This works because I develop in Windows using GHC 6.10.4 wxHaskell 0.11.1.2 - I haven't upgraded because I believe the GHCi behaviour worsens on later versions of GHC (I'm open to correction on this) - a student of mine has been able to build it on linux using the latest versions of everything - I had to revise some of my code simply because later GHC versions introduced new keywords So - to summarise If you are happy to develop using 6.10.4, on Windows then wxHaskell is workable with GHCi It seems to then build ok on Linux Alas - I have yet to be able to build it on Mac OS X (Snow Leopard) The app ? - see http://www.scss.tcd.ie/Andrew.Butterfield/Saoithin/ On 18 May 2011, at 00:24, Conal Elliott wrote: I still haven't found any way to do GUIs or interactive graphics in Haskell on a Mac that isn't plagued one or more of the following serious problems: * Incompatible with ghci, e.g., fails to make a window frame or kills the process the second time one opens a top-level window, * Goes through the X server, and so doesn't look or act like a Mac app, * Doesn't support OpenGL. A year or two ago, I put my Haskell GUI graphics work on hold while waiting hoping for a functioning pathway to open. So far I haven't heard of one. If anyone has found a solution, I'd love to hear! - Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204 Foundations and Methods Research Group Director. School of Computer Science and Statistics, Room F.13, O'Reilly Institute, Trinity College, University of Dublin http://www.cs.tcd.ie/Andrew.Butterfield/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
Is there a library that satisfies 2 of your 3 points? * Works with ghci * Supports OpenGL. I've struggled to get: * A window with opengl * Running interactively from ghci * Working cross platform Anyone know of a solution for that? If there's a library that handles that, then there's at least a sensible base to build a pure functional GUI system on. Cheers, Sam From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Conal Elliott Sent: 18 May 2011 00:24 To: Haskell Cafe Subject: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics I still haven't found any way to do GUIs or interactive graphics in Haskell on a Mac that isn't plagued one or more of the following serious problems: * Incompatible with ghci, e.g., fails to make a window frame or kills the process the second time one opens a top-level window, * Goes through the X server, and so doesn't look or act like a Mac app, * Doesn't support OpenGL. A year or two ago, I put my Haskell GUI graphics work on hold while waiting hoping for a functioning pathway to open. So far I haven't heard of one. If anyone has found a solution, I'd love to hear! - Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
Quoth =?iso-8859-1?Q?Jurri=EBn_Stutterheim?= j.stutterh...@me.com, ... So here's my (perhaps slightly provoking) question: do we need to care at all about good GUI toolkits being available? Web applications, especially with an HTML 5 front-end, have become increasingly more powerful. If we can also find a good, standardized way to generate JS from our Haskell code, we're pretty much all set. That isn't so controversial - do we need to care about good GUI toolkits being available? Evidently not, we can say that from the fact that we're still looking for GUI support on the Mac in 2011. The Web application idea might be a useful workaround for some, like X11 may be acceptable for others, but these could be thought of as exceptions that prove the rule. If that's enough to solve the problem, then there would appear to be little call for Mac GUI applications. My only Haskell application on my ancient PPC Mac uses the terminal, but long ago I tried a Haskell Cocoa library, HOC, that would have supported native graphics, if it had worked for me. Has anyone taken that route with an application? I have been using native API graphics on another more obscure platform (Haiku), of course not portable but much easier to get working than the gigantic cross platform GUI toolkits, and maybe that would address the chicken vs egg problem that helps make Mac GUI apps a non-issue for Haskell. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
On Wed, May 18, 2011 at 11:09 AM, Jason Dagit dag...@gmail.com wrote: Support for OpenGL comes in different levels of quality, as I'm discovering. It would seem that Mesa (ie., linux support), only officially supports OpenGL 2.1 [1] despite being released on 6 April 2011. I haven't been able to get OpenGL 3.0+ specific features to work on linux with Haskell yet. [1] http://www.mesa3d.org/relnotes-7.10.2.html Sorry, I forgot the link! Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
On Tue, May 17, 2011 at 4:24 PM, Conal Elliott co...@conal.net wrote: I still haven't found any way to do GUIs or interactive graphics in Haskell on a Mac that isn't plagued one or more of the following serious problems: * Incompatible with ghci, e.g., fails to make a window frame or kills the process the second time one opens a top-level window, * Goes through the X server, and so doesn't look or act like a Mac app, * Doesn't support OpenGL. Support for OpenGL comes in different levels of quality, as I'm discovering. It would seem that Mesa (ie., linux support), only officially supports OpenGL 2.1 [1] despite being released on 6 April 2011. I haven't been able to get OpenGL 3.0+ specific features to work on linux with Haskell yet. I find that you really want OpenGL 3.1 or newer. The Khronos group really did a lot of nice things with the 3.x specification and 4.x is even better. Some people in this thread have suggested doing web apps. This won't work well yet for people who want OpenGL support. My experiments with webgl show that it's not mature yet. You have to target a specific browser and OS at the moment, with linux having the worst support by far. Firefox 4 and Chrome on windows fair the best so far. A year or two ago, I put my Haskell GUI graphics work on hold while waiting hoping for a functioning pathway to open. So far I haven't heard of one. Yes, I know the feeling all too well. I'd like to fix this situation. I took over maintainership of the Haskell OpenGL bindings hoping that I could improve them. We now have a google summer of code student working on the bindings to update them and improve the overall quality. That's just one piece of the puzzle. If you'd like to contribute to that piece of the puzzle we have an organization on github for Haskell OpenGL: https://github.com/haskell-opengl Send some pull requests or add bug tickets! As you point out we also need better libraries for creating the OpenGL context. I wrote up my searches on that front here: http://blog.codersbase.com/2011/03/picking-gui-library-to-use-with-opengl.html My conclusion was that GLFW-b (on hackage) is the best we have right now. I think we could do even better than the C libraries out there by writing the GLUT/GLFW/etc implementation purely in Haskell. We already have x11 and gtk bindings for the linux support. We have win32 api bindings for windows support. What we are lacking is good low level support for OSX GUI programming. Once we have that it's not too much of a stretch to use cabal to glue it together into a cross platform library. I believe that's the right way to go for the long term. Improving GLFW-b is a good short-term route. And just to say it one more time, I can use all the help I can get. There are a lot of yaks to be shaved. My hope is that if we all shave one yak then we'll quickly have the libraries we need to do some serious graphics hacking in Haskell. We already have many good libraries for it, we just need to improve and polish a few key libraries. The momentum is here and a few people have already jumped in. Time to get on board! Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
On 5/18/11, Donn Cave d...@avvanta.com wrote: Quoth =?iso-8859-1?Q?Jurri=EBn_Stutterheim?= j.stutterh...@me.com, ... So here's my (perhaps slightly provoking) question: do we need to care at all about good GUI toolkits being available? Web applications, especially with an HTML 5 front-end, have become increasingly more powerful. If we can also find a good, standardized way to generate JS from our Haskell code, we're pretty much all set. That isn't so controversial - do we need to care about good GUI toolkits being available? Evidently not, we can say that from the fact that we're still looking for GUI support on the Mac in 2011. I'd give three reasons for disagreeing: 1. Developing a complete GUI has been a low priority up until now, but now that other, more urgent areas of development are starting to thrive, its time has come. 2. Yes, having essentially no complete GUI support has suited our needs up until now, but these have been the needs of a certain type of programmer. IF the community would like to grow, or would like to be able to use Haskell at work, I'd say a GUI supporting the above would be very valuable. 3. Using the web as Haskell's main method of non-command line (graphical) deployment seems to lose two of Haskell's most powerful features: its type safety, and its speed. If we use Haskell essentially as a JS abstraction layer, we lose all type safety (in the event that anyone goes in and tinkers with the generated JS). A main reason people are showing interest in FP is because of purity, and therefore its potential speed on multicore machines. If we just generate to JS, this is also lost. In fact, speed on single-core machines is lost also. Again, my 2¢, Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
My conclusion was that GLFW-b (on hackage) is the best we have right now. I think we could do even better than the C libraries out there by writing the GLUT/GLFW/etc implementation purely in Haskell. We already have x11 and gtk bindings for the linux support. We have win32 api bindings for windows support. What we are lacking is good low level support for OSX GUI programming. Once we have that it's not too much of a stretch to use cabal to glue it together into a cross platform library. I believe that's the right way to go for the long term. Improving GLFW-b is a good short-term route. Would it be possible to do it with wx? There would be a much larger potential developer pool, since it's cross-platform. (Not getting away from C libraries, but they're stable). And just to say it one more time, I can use all the help I can get. There are a lot of yaks to be shaved. My hope is that if we all shave one yak then we'll quickly have the libraries we need to do some serious graphics hacking in Haskell. We already have many good libraries for it, we just need to improve and polish a few key libraries. The momentum is here and a few people have already jumped in. Time to get on board! Count me as onboard; I'm just not sure which ship I'm on yet. Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
Thanks, Heinrich! I tried your sample code (having grabbed compiled EnableGUI.hs). Works okay, including multiple calls to 'main'. There are a few subtle quirks. I don't see the usual bottom-right resize icon (three parallel lines at 45 degrees), and the Zooom/2 program for convenient window moving resizing isn't able to move resize this one window. Have you noticed something similar? - Conal On Wed, May 18, 2011 at 12:33 AM, Heinrich Apfelmus apfel...@quantentunnel.de wrote: Conal Elliott wrote: I still haven't found any way to do GUIs or interactive graphics in Haskell on a Mac that isn't plagued one or more of the following serious problems: * Incompatible with ghci, e.g., fails to make a window frame or kills the process the second time one opens a top-level window, * Goes through the X server, and so doesn't look or act like a Mac app, * Doesn't support OpenGL. A year or two ago, I put my Haskell GUI graphics work on hold while waiting hoping for a functioning pathway to open. So far I haven't heard of one. If anyone has found a solution, I'd love to hear! I've asked a similar question on stackoverflow http://stackoverflow.com/questions/5868916/ and answered it myself. Basically, GLFW works (on my machine) as long as you don't call the GLFW.terminate function. The answer includes an example program that you can try out. It might be worth to include the extra hoops (EnableGUI) in the GLFW package. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
On 18 May 2011 19:25, Tom Murphy amin...@gmail.com wrote: I'd give three reasons for disagreeing: 1. Developing a complete GUI has been a low priority up until now, ... I don't think that not having something as desireable good GUI suited anyone much, nor has it actually been a low priority - a lot of work has gone into the tools we have (and those that are now bit-rotted). It's more a case of an industrial level of effort is needed to develop and maintain a GUI solution. Java's Swing and Microsoft's Dot.Net had teams of programmers building them as loss leaders to establish their platforms. Similarly even GTK has had huge amount of resources invested in it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
Last I heard, wx still had the problem of crashing its host the second time one opens a window (which is typical in ghci). And last I heard, Jeremy O'Donoghue (cc'd) was exploring solutions but had very little time to pursue them. - Conal On Wed, May 18, 2011 at 11:42 AM, Tom Murphy amin...@gmail.com wrote: My conclusion was that GLFW-b (on hackage) is the best we have right now. I think we could do even better than the C libraries out there by writing the GLUT/GLFW/etc implementation purely in Haskell. We already have x11 and gtk bindings for the linux support. We have win32 api bindings for windows support. What we are lacking is good low level support for OSX GUI programming. Once we have that it's not too much of a stretch to use cabal to glue it together into a cross platform library. I believe that's the right way to go for the long term. Improving GLFW-b is a good short-term route. Would it be possible to do it with wx? There would be a much larger potential developer pool, since it's cross-platform. (Not getting away from C libraries, but they're stable). And just to say it one more time, I can use all the help I can get. There are a lot of yaks to be shaved. My hope is that if we all shave one yak then we'll quickly have the libraries we need to do some serious graphics hacking in Haskell. We already have many good libraries for it, we just need to improve and polish a few key libraries. The momentum is here and a few people have already jumped in. Time to get on board! Count me as onboard; I'm just not sure which ship I'm on yet. Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
Conal Elliott wrote: Thanks, Heinrich! I tried your sample code (having grabbed compiled EnableGUI.hs). Works okay, including multiple calls to 'main'. There are a few subtle quirks. I don't see the usual bottom-right resize icon (three parallel lines at 45 degrees), and the Zooom/2 program for convenient window moving resizing isn't able to move resize this one window. Have you noticed something similar? Indeed, same problem here. While I can resize the window, it doesn't show the corresponding icon. (I don't use Zooom/2.) This seems to be a problem with the GLFW library; you may want to file a bug report. I glean from Apple's documentation that a a judicious call to [window setShowsResizeIndicator:TRUE] at the time of window creation might solve the problem. Cocoa is always a little unpredictable when creating UI elements from scratch. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
Regarding 3: I was not implying that Haskell should be used only for replacing JS. Far from it. I was just saying that we need a solid way to generate JS from Haskell so that we can profit even more from Haskell's type safety and not have to suffer from the mess that is JS. My Snap-based application is also perfectly type-safe, on the server. It's fast too. :) On 18 May, 2011, at 20:25 , Tom Murphy wrote: On 5/18/11, Donn Cave d...@avvanta.com wrote: Quoth =?iso-8859-1?Q?Jurri=EBn_Stutterheim?= j.stutterh...@me.com, ... So here's my (perhaps slightly provoking) question: do we need to care at all about good GUI toolkits being available? Web applications, especially with an HTML 5 front-end, have become increasingly more powerful. If we can also find a good, standardized way to generate JS from our Haskell code, we're pretty much all set. That isn't so controversial - do we need to care about good GUI toolkits being available? Evidently not, we can say that from the fact that we're still looking for GUI support on the Mac in 2011. I'd give three reasons for disagreeing: 1. Developing a complete GUI has been a low priority up until now, but now that other, more urgent areas of development are starting to thrive, its time has come. 2. Yes, having essentially no complete GUI support has suited our needs up until now, but these have been the needs of a certain type of programmer. IF the community would like to grow, or would like to be able to use Haskell at work, I'd say a GUI supporting the above would be very valuable. 3. Using the web as Haskell's main method of non-command line (graphical) deployment seems to lose two of Haskell's most powerful features: its type safety, and its speed. If we use Haskell essentially as a JS abstraction layer, we lose all type safety (in the event that anyone goes in and tinkers with the generated JS). A main reason people are showing interest in FP is because of purity, and therefore its potential speed on multicore machines. If we just generate to JS, this is also lost. In fact, speed on single-core machines is lost also. Again, my 2¢, Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
On 5/18/11, Jurriën Stutterheim j.stutterh...@me.com wrote: Regarding 3: I was not implying that Haskell should be used only for replacing JS. Far from it. I was just saying that we need a solid way to generate JS from Haskell so that we can profit even more from Haskell's type safety and not have to suffer from the mess that is JS. My Snap-based application is also perfectly type-safe, on the server. It's fast too. :) Jurriën, I completely agree that we need a good JS generator. My response was just to the idea that web apps (with JS) could be a replacement for other GUI solutions. I wasn't implying you were saying we should only use Haskell for JS. Most useful Haskell apps right now are pretty GUI-free! Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
Jurriën Stutterheim: A few weeks ago I set out to build a GUI app using wxHaskell. Long story short, we ditched the entire idea of a desktop GUI and went for a web application instead, because it was easier to develop a front-end for it and it was easier to style it. So here's my (perhaps slightly provoking) question: do we need to care at all about good GUI toolkits being available? Web applications, especially with an HTML 5 front-end, have become increasingly more powerful. If we can also find a good, standardized way to generate JS from our Haskell code, we're pretty much all set. For cross-platform apps, I have to agree. The effort required to build and maintain a cross-platform GUI toolkit is hard to justify given HTML 5 and related technologies. Nevertheless, there are good reasons to develop native applications (especially on the Mac with its user-base spoiled by high-end UX). Luckily, the choice of toolkit is trivial in this case. For Mac OS, we need a Haskell-Cocoa binding. I don't think there are any serious technical obstacles to develop one. Somebody would just have to spend the time and effort to write one. Manuel On 18 May, 2011, at 08:29 , Tom Murphy wrote: I still haven't found any way to do GUIs or interactive graphics in Haskell on a Mac that isn't plagued one or more of the following serious problems: * Incompatible with ghci, e.g., fails to make a window frame or kills the process the second time one opens a top-level window, * Goes through the X server, and so doesn't look or act like a Mac app, * Doesn't support OpenGL. If there doesn't currently exist something without these handicaps, that's a serious problem for the use of Haskell for developing end-user software. If we as a community want to be able to develop software for end-users (i.e. people who'll be thrown off by gtk widgets or x11 windows)*, then it would be a very good idea to focus our energies on one or two promising pre-existing libraries, and hammer them into completion. A roadmap for this could be worked on at Hac Phi? Just my 2¢, Tom *This, of course, would NOT be avoiding success at all costs. :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
On 5/18/11 2:25 PM, Tom Murphy wrote: I'd give three reasons for disagreeing: 1. Developing a complete GUI has been a low priority up until now, but now that other, more urgent areas of development are starting to thrive, its time has come. 2. Yes, having essentially no complete GUI support has suited our needs up until now, but these have been the needs of a certain type of programmer. IF the community would like to grow, or would like to be able to use Haskell at work, I'd say a GUI supporting the above would be very valuable. 3. Using the web as Haskell's main method of non-command line (graphical) deployment seems to lose two of Haskell's most powerful features: its type safety, and its speed. I agree with these disagreements. Web apps have long been touted as a replacement for desktop apps. For certain specific kinds of domains people have been able to realize them sufficiently well as web apps. But I am still of the firm belief that there are numerous domains where browser-based UIs are wholly inappropriate. Thus, GUIs (especially OS-integrated GUIs) will remain a necessity for the foreseeable future. Moreover, for many people, the lack of native GUI support calls into question how mature and ready for serious work a language is; so developing a solid GUI story can be important publicity work. Beyond this, I can't say, since I rarely work on tools that require graphical interfaces. But I'd love to see a nice Cocoa--Haskell bridgework, since that's the kind of GUI I'm most liable to use/need. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
On 5/18/11 10:54 PM, Manuel M T Chakravarty wrote: Nevertheless, there are good reasons to develop native applications (especially on the Mac with its user-base spoiled by high-end UX). Luckily, the choice of toolkit is trivial in this case. For Mac OS, we need a Haskell-Cocoa binding. I don't think there are any serious technical obstacles to develop one. Somebody would just have to spend the time and effort to write one. Well, there may be some non-trivial technical work in figuring out how to do good Haskell-like high-level bindings, rather than low-level bindings that shove everything into IO. Also, ensuring type safety across the border is extremely non-trivial, especially because Objective C's object system is on the untyped/Smalltalk end of things. It's possible to just treat their types like they do, but I'm sure many Haskellers would prefer to make the typing more explicit and checkable (so long as it's still usable). But yes, the mere process of making bindings isn't especially cumbersome. Anyone interested in prior art should take a look at the Perl--ObjectiveC bridgework, CamelBones: http://camelbones.sourceforge.net/ -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
Quoth wren ng thornton w...@freegeek.org, ... But yes, the mere process of making bindings isn't especially cumbersome. Anyone interested in prior art should take a look at the Perl--ObjectiveC bridgework, CamelBones: http://camelbones.sourceforge.net/ Note (again) that there's already some work in this area, http://code.google.com/p/hoc/ My recollection from trying it several years ago was that there must indeed have been something especially cumbersome about it, given the prodigiously long time it would take to build an application, but it could be better now. In any case, I don't think it would be a crime to try a fresh start. With good Haskell-like high-level bindings, or not. If I were to work on it (as I was somewhat inspired to think about after reading Jason Dagit's comments), it would be the thinnest possible layer, with names unchanged and semantics preserved as possible. High level bindings can be applied on top of that, as required. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics
On 5/18/11, Manuel M T Chakravarty c...@cse.unsw.edu.au wrote: Nevertheless, there are good reasons to develop native applications (especially on the Mac with its user-base spoiled by high-end UX). Luckily, the choice of toolkit is trivial in this case. For Mac OS, we need a Haskell-Cocoa binding. I don't think there are any serious technical obstacles to develop one. Somebody would just have to spend the time and effort to write one. Can anyone point me to a good resource comparing the pros and cons of developing (say, Cocoa) bindings vs. using a cross-platform library with native look-and-feel like Wx? Thanks, Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Status of Haskell + Mac + GUIs graphics
I still haven't found any way to do GUIs or interactive graphics in Haskell on a Mac that isn't plagued one or more of the following serious problems: * Incompatible with ghci, e.g., fails to make a window frame or kills the process the second time one opens a top-level window, * Goes through the X server, and so doesn't look or act like a Mac app, * Doesn't support OpenGL. A year or two ago, I put my Haskell GUI graphics work on hold while waiting hoping for a functioning pathway to open. So far I haven't heard of one. If anyone has found a solution, I'd love to hear! - Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
