[GUI] haskell-gui: Second edition.
Mon, 3 Feb 2003 10:51:08 +0000
On Thu, Jan 30, 2003 at 03:21:40PM -0800, David Sankel wrote:
> 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
> 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
Which requirements? Gtk look resonably good for a Win32 user and crap for
> 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
> someone really wanted to write an application that
> looks absolutely native on all three platforms, they
> should write using:
> 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
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