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)
Hi David, On Thu, Jan 30, 2003 at 03:21:40PM -0800, David Sankel wrote:
(I think if I hear "why not just use gtk?" one more time, I'll pull out my teeth) Well, we agreed on this, I think. But you make your position very clear to start with...
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. To stir hatred: Gtk uses ANSI C and *runs* on all platforms :-)
[..]
The look and feel for all platforms deployed far succeeded our requirements. Which requirements? Gtk look resonably good for a Win32 user and crap for Aqua users.
[..]
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. A common GUI API should provide the maximum functionality which can still be expressed with the native look-and-feel. Designing this for Win32 and Unix is not that hard since most Unix toolkits have a strong influcence from the Windows world. Including Aqua is therefore more of a challenge, but I think most people will agree that this is a requirement: Since Apple has adopted a BSD core for their OS, the platform has gained a big momentum.
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. Yes, there is no way to avoid writing platform specific bits for real native look-and-feel (see Simon Marlow's mail and the screen shots of mxWindows [look at how the table widgets don't look native]). The aim of defining a common GUI API is to let every toolkit exhibit a part of its API with the common GUI API. An application written with just the common GUI API will run with all bindings (gtk2hs, Ports/HToolkit,...). A
If programmer who needs more only has to reimplement things which are not covered by the common GUI API. That's the goal. I think another binding to a Unix GUI toolkit is rather low priority at the moment. But if you whish to start, I strongly recommend to automate as much as possible, specifically - create the type definitions from a text file into one common file which can be included by everything else - create callback definitions automatically, if possible. This makes it possible to add exception handling at a later stage - parse the documentation and create all standard functions automatically, use an exception dictionary for more difficult functions - use e.g. c2hs for creating C function stubs and hsc2hs to marshal structures. The former ensures that you know when the C function changes it's signature (probably not important if you have to write C wrappers around C++ classes), the latter allows for reliable marshalling especially when you change from gcc's struct layout to Microsoft's. - get the memory management right by using ForeinPtrs Good luck, Axel.
participants (2)
-
Axel Simon -
David Sankel