--- David Sankel
1. Platform independance: The QT widget library is a stunning example of how platform independance is achievable without sacraficing speed. I am 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).
I am already started development in that way. There is one Haskell library with two backend one for Win32 and other for GTK. The backends are written in C and over that is the Haskell layer. The development of backends was started in my first attempt to port ObjectIO to GTK. But the trouble with ObjectIO was that its current implementation is too Windows specific for that reason I was started HToolkit project at SourceForce. In the new project, the backends are extended far away behind ObjectIO limitations. In the last few weeks we together with Daan Leijen was started development of the new Port library. The goal is to separate HToolkit GUI library in two levels. The low level is a simple portable library with raw IO interface and the high level is HToolkit. This allows development of several high-level interfaces with common low-level. I completely agree that the standard GUI must have different backends in the different platforms. I am completely agree with Wolfgang Jeltsch:
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
In addition: I don't like to use nonnative libraries like GTK on Windows. Why need I use GtkButton widget when there is the standard BUTTON window? Krasimir __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com