Portable GUI levels (was: Re: [GUI] Re: Gtk and Object I/O)

[Daan Leijen]

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