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