[Haskell-cafe] Status of Haskell + Mac + GUIs & graphics

Evan Laforge qdunkan at gmail.com
Fri May 20 03:48:43 CEST 2011


On Thu, May 19, 2011 at 5:32 PM, Felipe Almeida Lessa
<felipe.lessa at gmail.com> wrote:
> On Thu, May 19, 2011 at 9:23 PM, John Lask <jvlask at 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.



More information about the Haskell-Cafe mailing list