[GUI] Proposal Proposal: haskell-gui addendum to haskell standard

[Wolfgang Jeltsch]

On Wednesday, 2003-01-22, 17:40, CET, David Sankel wrote:
> [...]
> 1.  Platform independance:  The QT widget library is a stunning example=
 of
> how platform independance is achievable without sacraficing speed.  I a=
m not
> suggesting that we build haskell-gui off of QT but might use major
> components of it as a model. Eventually, the library could have three
> backends; the Windows API, the X API (or gtk perhaps?), and the Mac API=
 (the
> name illudes me at the moment).

In my opinion the big problem of Qt and similar libraries is that they ar=
e not=20
based on high level APIs. For instance, under Windows, Qt doesn't use the=
=20
support for handling buttons, checkboxes etc. that Windows provides but=20
provides its own handling of these widgets. Some drawbacks of such a conc=
ept=20
are:
    (1) The look and feel of applications written with the multi-platform
      library will probably differ from that of native applications.
    (2) The library will not properly use settings made in a platform-spe=
cific
      way like, for example, file type settings which should be used in f=
ile
      selection dialogs.

Qt is IMO fine as the basis of KDE but not so fine as a multi-platform GU=
I=20
library. IMO, APIs, a Haskell multi-platform GUI should be based on, shou=
ld=20
be as high level as possible. Also consider, that today the graphical asp=
ect=20
of the user interface is not everything. It would be nice if such a libra=
ry=20
would also care, for instance, about accustic signals.

I would propose the following backends for the library:
    * KDE (not just Qt)
    * Windows API or .NET
    * some reasonable MAC library (I think there are two at the moment.)

> 2.  Signals support:  Having a signals mechanism is essential for large=
 gui
> projects.

I'm not a Haskell GUI expert but I wonder if there is a more "haskellish"=
=20
solution here.

> 3.  Dynamic widgets:  All widgets should have dynamic size and should h=
ave
A the ability to be resized by the measurement of their contents or their
parents.  This could be done in a way similar to QT widgets.

I totally agree with you here. Again I would like that a multi-platform=20
library is based on the API which is as high level as possible. This mean=
s=20
that I would use the Qt resizing mechanisms under KDE and a custom=20
implementation of resizing under Windows (since, AFAIK, there is no resiz=
ing=20
provided by the Windows API nor the .NET API).

> 4.  GUI GUI builder:  Widgets should be flexible enough to have the abi=
lity
> to be incorporated in a GUI GUI builder program, such as QT designer.  =
The
> storage for a GUI builder might be direct Haskell code or some intermed=
iate
> format.

No opinion here.

> 5.  OpenGL incorporation:  haskell-gui should have some sort of OpenGL
> widget as OpenGL is the most standardized and multiplatform graphical
> library availible.  Perhaps the hgl software could be incorporated in t=
his
> aspect of haskell-gui.

Again, I totally agree with you.

> 6.  Custom Widgets:  It should be easy for one to create his or her own
> custom widgets from scratch using Haskell code or by some modification =
of
> the standard ones.

Total agreement.

> Please give your feedback and suggestions for this project proposal
> proposal.  If there is enough interest, I'll get this thing started.

I think, there was already a consensus concerning the development of a=20
standard Haskell GUI interface. The strategy was to develop a rather=20
imperative interface which could be implemented using different=20
APIs/underlying libraries and on which different "haskellish" GUI solutio=
ns=20
could be based.

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

Wolfgang Jeltsch