Most popular libraries not in the HP

[Axel Simon]

Hi Don, Heinrich,

On Jul 18, 2010, at 9:58, Heinrich Apfelmus wrote:

> Henk-Jan van Tuyl wrote:
>> Don Stewart wrote:
>>> Questions remain about what GUI lib to bring in, to augment the  
>>> OpenGL
>>> suite.
>>>
>>>    * gtk2hs
>>>    * wxHaskell
>> I tried GTK+ (with gtk2hs) a few years ago, together with Glade  
>> (the windows designer for GTK+), and found many serious bugs in a  
>> short time. I decided not to use it. It might just have been the  
>> Windows port that has these bugs; SourceForge showed that only one  
>> person was working on that port. That is not the only downside: it  
>> has an LGPL license.
>

I have tried to maintain Gtk2Hs for decade now and saw various people  
come and go. I admit that I don't write much GUI code myself and don't  
know how complete the API is and how many bugs are still lurking in  
the code. I've spend most of my time working around various build bugs  
and the adaption to the various Gtk+ and ghc versions. Also, I don't  
know if the bugs you found relate to Gtk+ or to Gtk2Hs. I guess that  
distinction doesn't really matter to the end user, but I think it  
matters to the decision of blessing Gtk2Hs as some sort of default GUI  
toolkit.

With respect to the license: Gtk+ is LGPL and we simply used the same  
license. I think I can convince the relevant contributors to change  
the license of Gtk2Hs to BSD or whatever is more convenient. wxWidgets  
is "essentially LGPL with an exception stating that derived works in  
binary form may be distributed on the user's own terms". So if this  
"downside" you're talking about has to do with shipping commercial  
Haskell GUI applications, I think we can easily find satisfactory  
solution. After all, wxWidget uses the LGPL'd Gtk+ toolkit on Linux.

> I'm on MacOS and it's similar for me. GTK just keeps crashing  
> randomly or behaving weirdly, reducing the utility of cool tools  
> like  hp2any .
>

The same question: do you mean Gtk2Hs or Gtk+? If it's the former,  
then we should fix the bugs. We are about to release Gtk 0.11.1 which  
has hopefully now all the concurrency bugs ironed out. Having  
cabalized Gtk2Hs, I hope users find the libraries more inviting to  
send in patches since it's now fairly simple to understand how to  
build the beast.

> Even if it's not a native GUI on MacOS, I'd at least accept gtk2hs  
> if it were bundling a precompiled version of the GTK libraries that  
> just works (tm).
>

I hope that the Aqua port of Gtk+ will mature eventually and that Gtk+  
reaches a similar look-and-feel as Qt on the major three platforms. It  
will never be perfect, but if there's some sort of abstraction for the  
menu bar and some good themes, then it might be acceptable to most  
people. Having Gtk2Hs in the platform would then be very convenient as  
it would relieve the user from the burden of installing all those  
different binary libraries. I am not willing to invest the time to  
provide a Mac and Windows installer just for Gtk2Hs since then I  
always have to track the ghc and platform releases and opens a lot of  
different platform problems that cabal currently abstracts for me.

Cheers,
Axel