[GUI] haskell-gui: Second edition.

[Axel Simon]

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.

  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.
 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

Good luck,
Axel.