Hello everybody, I'll try to keep this short, but I too have been getting frustrated by the current gui situation for Haskell and beem wondering what to do about it. I must confess that of all the people who've contributed to this thread I probably have the least experience of actually doing anything like this so fell free to ignore me :-), but here I my thoughts in no particular order .. Concurrency ----------- As far as what a gui api should look like we should be thinking about concurrent reactive systems generally, not just gui's (I assume we all want our gui to be concurrent). I would prefer not to have to deal with different concurrency models for the gui and non-gui parts of my programs. I was quite impressed by the approach taken in O'Haskell which seemed pretty much in accordance with my intuitions on this from years of doing similar stuff in embedded systems. But maybe I'm letting evil imperative thoughts cloud my judgement. The other possibility is FRP which was supposed to be the basis of FRUIT. I don't have enough experience with this approach to form an opinion. Portability ----------- This is the most important thing to me. The Qt toolkit seems to me to be one of the most portable around, I did start writing a binding to this but have now abandoned this approach for the following reasons.. 1- It's only free for Xfree86 2- Producing Haskell code "objects" to use in a library written in C++ (using virtual methods etc..) is not at all easy. Not impossible I think, but really awkward and horrible (and a good reason not to consider WxWindows too IMHO). 3- Dealing with memory management and garbage collection of complicated data structures which live partly in C land and partly in Haskell land seemed like a nightmare I could happily live without. I never did figure out a solution for that (it seems to require very detailed knowledge of what references what in C land if space leaks and dangling pointers are to be avoided). Native "Look and Feel" ---------------------- Others will disagree, personally I don't care much about this. Having a "quality look and feel" is important I think, but whether or not it looks like every other App on a particular platform seems unimportant to me. Achieving this using the whatever are regarded as standard platform libraries (such as MFC) seems hard to reconcile with portability. Writing a custom layer for each platform to match such complex libraries too an equally complex but totally different standard Haskell api seems to be asking a lot from whoever is doing the porting. So this is what I'm thinking now.. 1- Forget about interfacing to Gtk,Qt,MFC,TK,WxWindows or whatever. Instead write the entire thing in Haskell (preferably), C (if necessary) and perhaps even the occasional bit of assembler for stuff that must really fly using MMX,Altivec.. 2- Keep the platform specific stuff primitive and relatively simple to implement on any platform. Just basic window management,mouse and keyboard event event handling and blitting pixels to windows. Maybe we need to also consider desktop features like cut&paste and drag&drop here too. IMHO these primitives are the only things that would need to be standardised across all platforms. I'm not sure I see any benefit in standardising higher level gui libraries & apis (which should be completely portable anyway if written in Haskell/C). So with this in mind I've been doing some preliminary thinking and coding of 2D scaleable graphics library (something like cross between postscript and SVG) which can easily be called from Haskell. For font handling I've decided to use the freetype library. Other general purpose anti-aliased rendering, alpha blending etc..I intend to write myself. As for platform independent window handling and fast blitting, I looked at SDL, but this seems to have been designed with games in mind and is not really suitable gui's (the seriously crippling constraint being support for only 1 window). GLUT looks a bit more promising and the downloading the GLUI library and playing with the examples re-assures me that something like this is feasible (maybe using OpenGL too, as GLUI does). Or maybe it would be better to write something specifically tailored for a Haskell gui. For those who like native look and feel, this approach would not prevent an MFC look-alike widget library from being used (if somebody feels inclined to write one:-) Hmm..maybe that wasn't so short after all. Anyway, I'd be interested in collaborating with anybody else who thinks this is a reasonable approach. Regards -- Adrian Hey