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)