Hi All, Let me rephrase shortly what Simon has already rephrased :-). There are three different levels, a middle-ground GUI library in the IO monad, called (A). A low-level interface called (L) and a "target" that we map too (T). The target (T) is any available GUI library, like the portable GTK, win32, Qt, Aqua, Tcl/Tk, Xlib, but also Gtk2Hs, the haskell Win32 library or HaskellTk. Higher level libraries like Fruit, FranTk etc, can be implemented on top of (A) (or maybe (L)). The goals of (A) are: - reasonably easy for programmers to use - programmer's interface does not change across targets - at first: rich enough to be useful + should have enough flexibility to evolve in time into an industrial-strength library The goals of (L) are - Reasonably easy to implement (but maybe less easy to program with) - Programmer's interface (from "above") does not change across targets - Rich enough to implement (A) + Exposing platform dependent handles for extensibility + Very flat and abstracted interface -- otherwise, we could just as easily use Qt, the Java AWT/Swing, IBM's SWT or GTK directly! This also means that the (L) layer will never be as powerful as using the underlying toolkit directly. Because of this, (L) needs to expose the 'handles' to allow power-users to bypass (L) and call the underlying toolkit directly (= not portable). There are an enormous amount possible choices in implementing some GUI library for Haskell: ranging from implementing a complete do-it yourself toolkit, via native toolkits, to using portable toolkits like Qt. ** However, in the end, all these approaches will end up exposing an interface like (L)!! (if only internally). *** I therefore think that we should try to focus this discussion on how (L) (and (A)) should look like, instead of trying to compare all possible implementation routes. Let us try to define a (L) interface and let people implement it using their favorite platform. What I am proposing is to use Port as a concrete proposal for how the (L) interface should look like. Not that Port is complete, or "just right", but because it exists, is still quite small, has implementations on top of both GTK and Windows, and seems suitable for implementing an (A) library (i.e. GIO). (haddock docs: http://www.cs.uu.nl/~daan/doc/port) (cvs: http://sourceforge.net/projects/htoolkit) Another concrete proposal could be the (L) layer of the ObjectIO library. The great thing about the ObjectIO interface is that it has been used in large projects and that people have lots of experience with it. However, at the same time the library is rather cumbersome to use from Haskell (it has some Clean quirks) and has only been implemented for Windows. I am not aware of other (L) layers that are suitable for Haskell but I am looking forward to hear more about that. All the best, Daan. ----- Original Message ----- From: "Simon Peyton-Jones" <simonpj@microsoft.com> To: "Adrian Hey" <ahey@iee.org>; <gui@haskell.org> Sent: Friday, January 24, 2003 5:35 PM Subject: RE: [GUI] Re: Gtk and Object I/O
| > Peter Aachten goes further. Based on the Clean group's experience, he | > thinks we can not only define a satisfactory (A), but also define a | > lower-level interface (expressed in the C language) that | > suffices to support (A) | > and yet contains no target specific code
I phrased this badly. What I meant was this. Let's call the lower-level interface (L). Let's call the thing we are mapping to the "target". A target is either a portable library like GTK, or a native UI platform like Windows. A target is something we don't implement.
The goals of (A) are: Reasonably easy for programmers to use Programmer's interface does not change across targets Rich enough to be useful
The goals of (L) are Reasonably easy to implement (but maybe less easy to program with) Programmer's interface (from "above") does not change across targets Rich enough to implement (A)
As I understand it: ObjectIO and Daan's Graphics.UI.GIO are examples of (A)
Daan and Krasimir's Port is an example of (L)
When I said "contains no target-specific" code, I meant that the code that implements (A) using (L) is not target specific. The implementation of (L) will certainly be target specific.
You are right that (L) does not need to be written in C. Indeed there might be many implementations of (L): some which are entirely in Haskell (perhaps implemented by you), others written mostly in C (using existing libraries).
I know little about particular UI libraries. My suggestion, though, is that we focus discussion on what (A) and (L) should look like, rather than on how they should be implemented.
Simon
_______________________________________________ GUI mailing list GUI@haskell.org http://www.haskell.org/mailman/listinfo/gui