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
|

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

Eric Kow
On Wed, May 18, 2011 at 15:06:02 -0400, Tom Murphy wrote:
> Is there a way to build an installer that would make this process easier?

I've sent a pull request to the maintainer of homebrew.
Hopefully it should then just be a matter of brew install wxmac

Homebrew's wxWidgets already builds 32 bit, but it omitted the
enable-unicode, which is what my patch fixes)

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

Jeremy's blog seems to talk about this:
  http://wewantarock.wordpress.com/ 


I remember that the impression that Brian Lewis was also looking into
this at some point
http://www.mail-archive.com/wxhaskell-users@.../msg00744.html

If anybody knows what this "unknown symbol `__dso_handle'" means and
what we can do about it, it could be a great help

I wonder if GHC 7 makes any of this easier...

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

Manuel M T Chakravarty
In reply to this post by J. Stutterheim
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
>> [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

wren ng thornton
In reply to this post by amindfv
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
[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

wren ng thornton
In reply to this post by Manuel M T Chakravarty
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
[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
Quoth wren ng thornton <[hidden email]>,
...
> 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
[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 Manuel M T Chakravarty
On 5/18/11, Manuel M T Chakravarty <[hidden email]> 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
[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 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.

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
[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 Jason Dagit-3
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
[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:
> 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
[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

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


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

Re: Status of Haskell + Mac + GUIs & graphics

KC
In reply to this post by Conal Elliott
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 <[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.
>
> 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
>
>



--
--
Regards,
KC

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

Re: Status of Haskell + Mac + GUIs & graphics

Felipe Lessa
In reply to this post by John Lask
On Thu, May 19, 2011 at 9:23 PM, John Lask <[hidden email]> 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
[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

Evan Laforge
On Thu, May 19, 2011 at 5:32 PM, Felipe Almeida Lessa
<[hidden email]> wrote:
> On Thu, May 19, 2011 at 9:23 PM, John Lask <[hidden email]> 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
[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

Jeremy O'Donoghue
In reply to this post by Conal Elliott
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 <[hidden email]> 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 <[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

Jeremy O'Donoghue
In reply to this post by Heinrich Apfelmus
On 19 May 2011 14:01, Heinrich Apfelmus <[hidden email]> 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
[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)

Jeremy O'Donoghue
In reply to this post by Eric Kow
On 19 May 2011 00:03, Eric Y. Kow <[hidden email]> wrote:
On Wed, May 18, 2011 at 15:06:02 -0400, Tom Murphy wrote:
> Is there a way to build an installer that would make this process easier?

I've sent a pull request to the maintainer of homebrew.
Hopefully it should then just be a matter of brew install wxmac

Homebrew's wxWidgets already builds 32 bit, but it omitted the
enable-unicode, which is what my patch fixes)

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

Jeremy's blog seems to talk about this:
 http://wewantarock.wordpress.com/


I remember that the impression that Brian Lewis was also looking into
this at some point
http://www.mail-archive.com/wxhaskell-users@.../msg00744.html

If anybody knows what this "unknown symbol `__dso_handle'" means and
what we can do about it, it could be a great help

It is a handle for a dynamic shared object. It is required for the case where __cxa_atexit() is called, which is when a shared library is unloaded. It is specifically required because there are C++ statics on which destructors should be called. The documentation says that __dso_handle should be unique to the shared library instance.
 
I wonder if GHC 7 makes any of this easier...

GHC7 may (should) fix the problem linking libstdc++.dll on Windows.

The static destructor problem probably requires 'true' dynamic loading and unloading of the wxWidgets DLL from within part of the wxcore wrapper code. Loading wxwidgets dll with dlopen() (Unix) or LoadLibrary() (Windows) will give us a DLL handle, and unloading with dlclose()/UnloadLibrary() will ensure that the destructors are called.

The problem is that doing this means that you only know the address of wrapper functions after they have been loaded (need to do a dlsym()/GetProcAddr() to fetch this info), and doing this for the several thousand functions in wxHaskell will require some automation to extract the information to generate the code to do this. The code should probably live in wxDirect, but I loose the will to live whenever I go digging there :-(

Regards
Jeremy

_______________________________________________
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

Jeremy O'Donoghue
In reply to this post by Evan Laforge
On 20 May 2011 02:48, Evan Laforge <[hidden email]> wrote:
On Thu, May 19, 2011 at 5:32 PM, Felipe Almeida Lessa
<[hidden email]> wrote:
> On Thu, May 19, 2011 at 9:23 PM, John Lask <[hidden email]> 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.
    • Of course, there are many reasons: licensing, general preference, primary platform used for development, religion etc. why people favour one or other toolkit. The problem is that I don't think we have the luxury of supporting them all.
      • E.g. my *primary* reason for choosing wxHaskell (over GtkHS) 5 years back was licensing. The detailed reasons are OT here.
      • Other will have other reasons - probably no less valid than my own.
  • 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.
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.

Best regards
Jeremy

_______________________________________________
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

Gregory Crosswhite-2
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
[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

Erik Hesselink
On Fri, May 20, 2011 at 20:39, Gregory Crosswhite
<[hidden email]> 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
[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

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