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

On Thu, May 19, 2011 at 5:32 PM, Felipe Almeida Lessa wrote:

On Thu, May 19, 2011 at 9:23 PM, John Lask 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.