[GUI] Re: Gtk and Object I/O

[Axel Simon]

Simon,

On Fri, Jan 24, 2003 at 01:11:02PM -0000, Simon Peyton-Jones wrote:
[..]
> My hope is that
> 
> (A) we can define programming interface (i.e. a collection of abstract
> 	types and functions)
> 
> (B) that is rich enough to be useful for writing GUI applications
> 
> (C) and yet can be mapped onto a variety of architectures and toolkits
> 
[..]
> 
> The question is: what should (A) look like?  Is it even possible to
> define a rich enough (A) without making (C) impossible? The answer to
> the latter question must surely be "yes, provided one is not too
> ambitious with (A)".
You mean "ambitious with (B)", I assume.

Again, reducing (B) automatically means affecting the look-and-feel. But 
for me this is not a severe issue.

> 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
No target specific code? I don't think I understand what you mean. The 
APIs are target specific. So where is the advantage of specifying the 
impedance matching code in C?

> 	what are the candidates for (A)?
> 
> I've suggested one: the Clean Object-IO model, or something related (the
> MVar vs local state question is still open).  Are there any other
> proposals?
I am happy with Object I/O concept as a medium layer. But I am very 
suspicious about the intermediate layer. You said you would go for a GUI 
interface which is reduced but portable and I fear that it is a very time 
consuming effort to find this layer. I believe that there are many people 
right now who want to write GUI applications who I think we should serve.

A proposal:

We start from different platforms:

- we have an Object I/O library for Win32 in ghc's CVS
- Gtk
- A native Aqua interface could be started

Can we extract the core infrastructure (no widgets) of Object I/O into a 
separate CommonGUI module which all these libraries use. We could then 
gradually define widget (and other) abstractions in the CommonGUI library 
and map them to all native libraries.

Advantages:
- People who want to do full fledged applications can do so right now 
using one of the native libraries.
- In the long run, we will have a CommonGUI library which restricts itself 
to elements which can be implemented with the native look-and-feel.


Any comments?

Axel.