Gtk and Object I/O

[Axel Simon]

Hi folks,

when I first asked Manuel (author of gtk+hs) if it is ok to make my Gtk
binding public, he said something along the lines of "I can't keep you
from making it public" and "I am not going to stop gtk+hs because of
this". So it seems we are all waiting for the critical user mass that
makes our own beloved GUI library (binding) the standard GUI library. For
the sake of Haskell, we can only hope that this will actually happen one
day.  A sad side-effects of this is that most of us GUI developers waste a
tremendous amount of time. A paper is just not worth the effort we put in 
writing the code.

More to the point:
On Fri, Jan 17, 2003 at 01:34:59AM -0800, Krasimir Angelov wrote:
> Dear Axel,
> 
> The Object I/O development is currently frozen. The
> native Win32 backend works but maybe still have bugs.
> I still support the library but only for bugfixes. I
> tried develop GTK backend for Object I/O but I found
> many difficulties. The main trouble is that the
> original Clean library are developed only for Windows.
> I think that Object I/O must be rewriten from scratch
> to make it more portable.

Up to here it sounded quite encouraging. My Gtk2 programs seem to be very
stable on Windows and - with careful design of the GUI - applications will
behave and look very similar to MFC applications IMHO.

Thus I thought that providing a known higher level layer similar to Object
I/O would serve the needs of most people who would like to build
applications with GUIs. Using the Object I/O techniques could attract 
those who have used this library before.
Of course, this layer on top of Gtk2hs would be new and incompatible,
simply because Gtk is so much different from Win32 when it comes to high
level GUI objects.


> For that reason I started my
> new project HToolkit
> (http://sourceforge.net/projects/htoolkit). The
> project maintain both GTK and native Win32 API. The
> library are separated in two levels. The low level is
> written in C and has two versions: for Win32 and for 
> GTK. I think that the low level part are mostly 
> completed (about 80-90% of GUI related Win32 and GTK 
> API).
...

> The last week Daan Leijen started development
> of Port library. This is very thin Haskell layer over 
> the low level C part. The idea is to make it reusable 
> in other high level GUI libraries.
Another library which is possibly portable (sorry)? Could you elaborate 
Daan?

> After its
> completion I will retarget HToolkit to use Port. I
> hope that for the feature the Port will be ported to
> Mac platform.

I am tempted to claim that a library which tries to use only native
high-level API functions is doomed to behave slightly different on the
various platforms (I heard that from Java). Furthermore, trying to unify
several APIs sounds like taking the intersection which in turn reduces the
functionality. I know that exactly this was proposed some years ago as a
basic GUI library for Haskell, but I personally doubt that a restricted
but portable GUI library serves anybody.
 
> I think that for the time being developers which want
> to use Haskell for development of large scale projects
> are a trouble. There are nine known GUI libraries:
> 
>    * Gtk+HS
>    * iHaskell
>    * Gtk2HS
>    * HTk
>    * TclHaskell
>    * Fudgets
>    * FranTk
>    * Object I/O
>    * Yahu
> 
> None of them are capable for large scale development 
> for some reason.
I might convert gtk2hs to the hierarchical module system which would break 
code. After that we only need to add bits here and there. A 
production-quality version 1.0 will be available this summer (That is the 
plan anyway).

> The HTk, TclHaskell, FranTk and Yahu 
> are based on Tcl/Tk. The Tcl/Tk backend are portable 
> but slow. The Gtk+HS, iHaskell, Gtk2HS are based on
> GTK. The backend is powerful and portable (GTK >= 2.0)
> but I prefer to use just native libraries on 
> different platforms.
I guess I should say "me too". But being portable is more important for 
the success of Haskell as a language.

> The Object I/O is Win32 specific.
> I think that there is a need of one portable and 
> efficient library.
I hope we all agree to this.

> I post this message to haskell@haskell.org 
> because I think that development of nice libraries 
> requires agreement of the entire Haskell Community on
> basic design lines.
Good idea.

Agreement is nice, but we cannot ask the community to vote for one library
and therewith force people to abandon their GUI projects. Each of us can
only hope that the very own GUI library becomes the de-facto standard.

> I am looking for people which are
> interested in the development of a "standard" GUI
> library.
Two answers: "Me too." and "I am.". But how can we proceed from here?

I think we should all be more flexible and communicate more openly and 
earlier. The latter probably would have avoided that I went off and did my 
own Gtk binding.

Axel.