[GUI] haskell-gui: Second edition.

[David Sankel]

Hello Everyone,

  I was doing a contract in New Mexico for a few days.
 I was certainly surprised to find ~100 messages in my
inbox concerning GUIs in haskell.  Aside from the
several digressions and repititions in the archive (I
think if I hear "why not just use gtk?" one more time,
I'll pull out my teeth), there was a wealth of
extremely valuable information.  It also shows that
there is a lot of (heated) interest.  So, I'm
officially going to get this project going.

  I'm going to try to address the concerns that I
though stood out:

1. Why do I suggest using QT as a basis?

I was suggesting using QT's feature set as a basis and
probably their methodology for multiplatforming.

The programmer-interface of QT, whether you want to
call it low, mid, or high-level works really well. 
I've designed and implemented a piece of
cross-platform CAD/CAM software (a great example where
UI is of extreme importance) using QT.  QT worked
wonderfully for this project.  No other GUI toolkit
out there (in any language) could have succeeded with
our given time constraints.  QT has been a success in
this project and countless others.  The look and feel
for all platforms deployed far succeeded our
requirements.

2.  Why not use QT itself?
  I assume this means using QT as a thin wrapper.

  a) QT is too high level of a library to just move to
another language.  Haskell certainly needs it's own
low-level library.

  b) QT isn't even written in standard c++.  I hate
pre-compiler steps (moc).

  c) QT is proprietary.  This is unacceptable for a
standard haskell gui library.

3.  Why not incorporate XML into the gui for a
document model?

  This is, of course, nice for certain gui situations.
 However, this is something that could be done after
the  mid-level libraries are complete.  So, for now,
I'll put this question on the shelf.

4.  Which system should be used for a reference
implementation?  (windows or linux)

  I don't really care.  Those who plan on
contributing, please tell me what OS you would prefer
to use.

5.  Is haskell ready for High level GUI?

  No.  Fudgets and friends are nice, but they are out
of the scope of this proposal.  Until something really
cool comes up, we can basically forget about high
level functional libraries in our context.

6.  Htoolkit/port/ObjectIO?

  These are the places to start this project. 
ObjectIO is not sufficient as is.  I'm leaning towards
the low-level/mid-level interfaces with an ObjectIO
type mid-level.  What do people think about the port
library as it is right now?

http://www.cs.uu.nl/~daan/doc/port/Graphics.UI.Port.html

What needs to be changed?

How can it be improved?

Is it flexible enough?

7. Concurrency?

What do you all think about this?  Is there anything
we can do specifically to integrate it into a GUI
library?

8. What about using other high level libraries?

For this project, I believe it to be easiest and best
to not use other high level c or c++ libraries as a
basis.

I agree mostly with Adrian's comments regarding this. 
Axil's comments were mostly discussing applications
and current work on this idea.

9. What about the Mac?

Macs are not a priority.  A Mac backend would be nice
but whether or not it adheres to the mac
recommendations on style are not important.  If
someone really wanted to write an application that
looks absolutely native on all three platforms, they
should write using:

gtk+hs
mac+hs
w32+hs

and not with haskell-gui.  I do not wish to get rid of
the other existing libraries.  On contrary, I hope
they continue progressing.  I wish for a standardized
gui framework for haskell.

David J. Sankel
Head Consultant
Electron Consulting (www.electronconsulting.com)