[GUI] Re: Gtk and Object I/O

[Adrian Hey]

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