Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

As the Haskell Wiki itself states:

There is a large number of GUI libraries for Haskell. Unfortunately there is no standard one and all are more or less incomplete. In general, low-level veneers are going well, but they are low level. High-level abstractions are pretty experimental. There is a need for a supported medium-level GUI library.

A professor at my college asked me and three other computer science majors to consider working on a GUI library for Haskell. His initial idea for the project was to write a layer on top of OpenGL that mimicked the morphic library found in Smalltalk; however, this is just a suggestion and other system are definitely worth consideration.

This brings us to the actual, multi-part question.

  1. For what level of abstraction should our library strive? The Haskell Wiki seems to indicate strongly that a medium-level GUI library would be preferred; however, a high-level library would still be welcome.
  2. Upon what should our library be built? (Ex. OpenGL)
  3. What existing GUI library would you like to see our library mimic (if any) and why? (Ex. PyGame, Morphic, Swing, etc)
  4. What features would you like to see our library implement or avoid? For example, the good people at Gnome might argue that the minimize button is unnecessary.
  5. Do you have any general suggestions?
  6. What clever name would you give this imaginary library? (Ex. HOT - Haskell Opengl Toolkit; HAWT - Haskell Advanced Windowing Toolkit)
share|improve this question

closed as off-topic by MichaelT, gnat, Kilian Foth, GlenH7, Bart van Ingen Schenau Mar 12 at 13:25

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions asking us to recommend a tool, library or favorite off-site resource are off-topic for Programmers as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it." – MichaelT, gnat, Kilian Foth, GlenH7
If this question can be reworded to fit the rules in the help center, please edit the question.

2  
Mimic Qt or GTK, those are wonderful –  Anto Mar 21 '11 at 5:26
    
Have you already seen haskell.org/haskellwiki/Reactive ? –  SK-logic Apr 1 '11 at 14:26
add comment

2 Answers

up vote 5 down vote accepted

I'd like to see a library which is elegant and simple to use with Haskell. The rest is technical details that should serve this purpose, not redefine it. Thus my $0.02.

Don't base it on an existing toolkit, like Qt or GTK or FLTK or... — this will severely limit you and will probably give you far more pain than profit. PyQt is, erm, funny and contrived enough, and both Python and C++ are extremely flexible imperative OO languages. In the case of Haskell, things would be much rougher, I suppose.

Depend only on the most basic graphic primitives, then build upon that. OpenGL is nice, but even something simpler (2D-only, e.g. SDL) would do well, too. This will give you maximum flexibility and maximum portability. See Smalltalk/Morphic, Java/Swing, TCL/Tk.

Make it conceptually small. GUIs are hard as they are, no need to add another Everest to climb. Haskell, I hope, can help make the thing compact and modular.

For bonus points, make it skinnable. As a minimum, know how to apply system colors (and only system colors) to paint your entire repertoire of controls, so that an app built with this toolkit is not a eyesore. As a maximum, know how to make Win32/Gtk/Qt/Cocoa draw your controls so that they look fully native. Basic skinnability is simple and logical; attaining full native look is quite hard.

Also, please run rootless and leave window management to the underlying graphic system — X, Windows, whatever. Not doing so will challenge users' sanity and hamper adoption drastically.

As usual, 'make simple things simple and complex things possible' + 'avoid the Turing tarpit where everything is possible but nothing of interest is simple' + 'make at as simple as possible but not simpler'.

The name is the least important thing. Of all popular GUI toolkits, only Qt has a somehow clever name. A number of popular projects changed names, even in-flight (Firefox, née Firebird). Have something to name, and you'll name it.

Good luck!

share|improve this answer
add comment

After talking amongst all of the students involved and giving this question sufficient time to generate interest, I believe we have come to a consensus on a few of the key questions in my original post.

For what level of abstraction should our library strive? The Haskell Wiki seems to indicate strongly that a medium-level GUI library would be preferred; however, a high-level library would still be welcome.

We decided to aim for a medium-level library per the Haskell Wiki's suggestion.

Upon what should our library be built? (Ex. OpenGL)

We chose OpenGL due to its popularity and support. We will be using either the GLUT or GLFW Haskell wrapper projects as a base.

What existing GUI library would you like to see our library mimic (if any) and why? (Ex. PyGame, Morphic, Swing, etc)

We chose Morphic after considerable debate between it and PyGame. We did not consider QT or GTK since both already have one or more Haskell library projects in active development.

What clever name would you give this imaginary library? (Ex. HOT - Haskell Opengl Toolkit; HAWT - Haskell Advanced Windowing Toolkit)

This is still up for debate. We have decided not to consider HAWT and instead are looking at:

  • HOT - Haskell Opengl Toolkit
  • HOG - Haskell Opengl Graphics (Make your project HOG powered!)
  • Schön
share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.