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 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).

In my opinion the big problem of Qt and similar libraries is that they are not based on high level APIs. For instance, under Windows, Qt doesn't use the support for handling buttons, checkboxes etc. that Windows provides but provides its own handling of these widgets. Some drawbacks of such a concept 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-specific way like, for example, file type settings which should be used in file selection dialogs. Qt is IMO fine as the basis of KDE but not so fine as a multi-platform GUI library. IMO, APIs, a Haskell multi-platform GUI should be based on, should be as high level as possible. Also consider, that today the graphical aspect of the user interface is not everything. It would be nice if such a library 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.

3. Dynamic widgets: All widgets should have dynamic size and should have A the ability to be resized by the measurement of their contents or their

I'm not a Haskell GUI expert but I wonder if there is a more "haskellish" solution here. 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 library is based on the API which is as high level as possible. This means that I would use the Qt resizing mechanisms under KDE and a custom implementation of resizing under Windows (since, AFAIK, there is no resizing provided by the Windows API nor the .NET API).

4. GUI GUI builder: Widgets should be flexible enough to have the ability 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 intermediate 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 this 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 standard Haskell GUI interface. The strategy was to develop a rather imperative interface which could be implemented using different APIs/underlying libraries and on which different "haskellish" GUI solutions could be based.

Kudos,

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

Wolfgang Jeltsch

I think that we have two alternatives: 1. Design the standard haskell GUI library as a mid-level, IO based library, in wich code would look like the following: win <- newWindow "Hello world" btn <- newButton "Bye" insert win btn onClick btn (close btn) and then design a high-level interface, because the IO based approach uncomfortable. 2. Directly plan the high-level interface, and create backends for it onto the various platforms. In both cases, don't forget that the gtk and gtk2 bindings are in an advanced state, and they already handle signals. I guess that those would be the first two "platforms" onto wich implement the library. Also, remember that both gtk and gtk2 are available on windows, macos, linux and freebsd. Regarding the high-level interface, first of all: it HAS to come. There's no real utility in a language like haskell if mainly used in the IO monad. We have many examples of declarative user interfaces (FRAN appears the to me, but it's just an opinion), and I think that a declarative UI would exploit the power of a declarative language, really speeding up the development of robust applications. Now, stated that it has to come, and considering that the gtk and gtk2 bindings already implement an IO based approach, perhaps the best thing to do would be to design the high level library, with use cases, and work on it until we find a reasonable model. Then we can implement that model on everything we want, qt, gtk, windows, macos etc. Another idea that is always present in my mind: we could also adopt a document model, for example the new standardized XML models that are coming from sun and other major companies cooperation around openoffice. This model could be implemented as an user interface, and would ease printing and cut and paste between different applications. Vincenzo

I believe that haskell would have great benifit from a platform independant specification for a graphical user interface module or set of modules. I've been blessed with a lot of time on my hands so I'd be willing to organize this project if needed.

I agree this is a big hole in Haskell's library support. IO/Higher level interface ------------------------- Haskell has a lot of high level GUI toolkits/proposals (ObjectIO/Haggis/Fudgets/Fran/etc) and a number of IO level interfaces which are more or (usually) less maintained. While programming at the IO level works, it does not give one much of an advantage versus programming in C, in sharp contrast to most other Haskell programming. The diversity of high level solutions which differ totally in outlook ("express the widget as a datastructure" versus "everything is a composition of functions") gives the impression that the library designers never used their toolkits in larger applications which would have made any rough edges painfully obvious. It seems therefore that a lot more work needs to go into this field before we know what a good high level Functional GUI toolkit looks like. Contrast this with more mature fields such as pretty printing, parsing, etc where there are many solutions all following the same ideas. Therefore while I would like to see a higher level interface than currently what seems best to me (a binding to GTK), it seems unlikely that this project will resolve that question completely. Perhaps the best would be to use an Object-IO like interface with mvars as proposed by Simon Peyton-Jones, simply because it's higher level than raw gui-calls and the Clean folks have used it cross-platform in a few real apps. SWT --- I have seen many positive comments about IBM's SWT which works on the following platforms: aix/motif hpux/motif linux/gtk linux/motif linux/qt macos/carbon qnx/photon solaris/motif win32/win32 win32-ce/win32 It's a java binding to a native interface layer. Perhaps the fact it is architected as a binding could ease the creation of a similar Haskell binding which would work on all those platforms. http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-swt-home/dev.ht... Sengan