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

[Jeremy O'Donoghue]

On 20 May 2011 02:48, Evan Laforge <qdunkan at gmail.com> wrote:

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


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20110520/cc140b3d/attachment.htm>