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.