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