Status of Haskell + Mac + GUIs & graphics

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

Status of Haskell + Mac + GUIs & graphics

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

Re: Status of Haskell + Mac + GUIs & graphics

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

Re: Status of Haskell + Mac + GUIs & graphics

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


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


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

Re: Status of Haskell + Mac + GUIs & graphics

Michael Snoyman
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 <[hidden email]>:

> 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
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

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

Re: Status of Haskell + Mac + GUIs & graphics

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

Re: Status of Haskell + Mac + GUIs & graphics

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

Re: Status of Haskell + Mac + GUIs & graphics

Andrew Butterfield
In reply to this post by Conal Elliott
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)




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

Re: Status of Haskell + Mac + GUIs & graphics

Donn Cave-4
In reply to this post by J. Stutterheim
Quoth =?iso-8859-1?Q?Jurri=EBn_Stutterheim?= <[hidden email]>,
...
> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

wxHaskell on Mac (Was: Status of Haskell + Mac + GUIs & graphics)

Eric Kow
In reply to this post by Andrew Butterfield
Hi

On Wed, May 18, 2011 at 09:18:42 +0100, Andrew Butterfield wrote:
>  Alas - I have yet to be able to build it on Mac OS X (Snow Leopard)

For what it's worth, I'm still using wxHaskell on MacOS X (also Snow
Leopoard)

The tricky bits are that you have to

1. install wxWidgets by hand, being sure to enable Unicode
   and to compile a 32 bit version:
 
   arch_flags="-arch i386"
   ./configure CFLAGS="$arch_flags"\
               CXXFLAGS="$arch_flags"\
               CPPFLAGS="$arch_flags"\
               LDFLAGS="$arch_flags"\
               OBJCFLAGS="$arch_flags"\
               OBJCXXFLAGS="$arch_flags"\
               --enable-unicode

2. do the Rez and app bundle magic which is now handily
   encapsulated in the cabal-macosx package on hackage

I also have patches to make it work with the latest Haskell Platform
and will put them on Hackage shortly assuming nobody objects
 
  darcs get --lazy http://darcsden.com/kowey/wxhaskell

Unfortunately, this does not address Conal's issue about using wxHaskell
with GHCi on Mac.  I do wish somebody had a free week to concentrate on
the issue.  Maintainer Jeremy made some progress on it, the last time I
checked...

--
Eric Kow <http://erickow.com>

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

attachment0 (202 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Status of Haskell + Mac + GUIs & graphics

Jason Dagit-3
In reply to this post by Conal Elliott
On Tue, May 17, 2011 at 4:24 PM, Conal Elliott <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Status of Haskell + Mac + GUIs & graphics

Jason Dagit-3
On Wed, May 18, 2011 at 11:09 AM, Jason Dagit <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Status of Haskell + Mac + GUIs & graphics

amindfv
In reply to this post by Donn Cave-4
On 5/18/11, Donn Cave <[hidden email]> wrote:

> Quoth =?iso-8859-1?Q?Jurri=EBn_Stutterheim?= <[hidden email]>,
> ...
>> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Status of Haskell + Mac + GUIs & graphics

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

Re: wxHaskell on Mac (Was: Status of Haskell + Mac + GUIs & graphics)

amindfv
In reply to this post by Eric Kow
> The tricky bits are that you have to
>
> 1. install wxWidgets by hand, being sure to enable Unicode
>    and to compile a 32 bit version:
>
>    arch_flags="-arch i386"
>    ./configure CFLAGS="$arch_flags"\
>                CXXFLAGS="$arch_flags"\
>                CPPFLAGS="$arch_flags"\
>                LDFLAGS="$arch_flags"\
>                OBJCFLAGS="$arch_flags"\
>                OBJCXXFLAGS="$arch_flags"\
>                --enable-unicode

Is there a way to build an installer that would make this process easier?


> Unfortunately, this does not address Conal's issue about using wxHaskell
> with GHCi on Mac.  I do wish somebody had a free week to concentrate on
> the issue.  Maintainer Jeremy made some progress on it, the last time I
> checked...

Do you have the link for the progress so far?


Tom

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

Re: Status of Haskell + Mac + GUIs & graphics

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


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

Re: Status of Haskell + Mac + GUIs & graphics

Stephen Tetley-2
In reply to this post by amindfv
On 18 May 2011 19:25, Tom Murphy <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Status of Haskell + Mac + GUIs & graphics

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


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

Re: Status of Haskell + Mac + GUIs & graphics

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

Re: Status of Haskell + Mac + GUIs & graphics

J. Stutterheim
In reply to this post by amindfv
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 <[hidden email]> wrote:
>> Quoth =?iso-8859-1?Q?Jurri=EBn_Stutterheim?= <[hidden email]>,
>> ...
>>> 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
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe


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

Re: Status of Haskell + Mac + GUIs & graphics

amindfv
On 5/18/11, Jurriën Stutterheim <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
123