[GUI] Know you backends (was: Re: Portable GUI levels)

[Axel Simon]

On Sat, Jan 25, 2003 at 06:39:06PM +0100, Daan Leijen wrote:
> Hi Axel,
> 
> > Because gtk2hs exists and is availabe on all three platforms, everybody 
> > gets the benefit of a complete, professional interface right now, so 
> > everyone should accept it as standard and not mourn about the slight 
> > differences in UI appearnce :-)
> 
> This is actually a rather good argument in favor of GTK. However, the
> GTK interface does not satisfy the constraint that it must be reasonably
> easy to implement.
It runs on the XonX implmentation of MacOS X. So one could argue that it 
is already implemented.

People here expressed the wish for using the native UI elements and the 
native way of presenting information and interaction with the user 
(look-and-feel). I grant that Gtk does not deliver this on Aqua and not 
100% on Windows.

> If someone wants a backend for Aqua or whatever,
> it is extremely hard to create a gtk implementation from scratch. The world
> would be good place when gtk would be the standard library for writing
> gui's, but right now, the toolkit is mainly portable across unix platforms.

Again, for the log-book: gtk2hs runs on Win32, Unix and MacOS X.

>  
> > I think existance is not a very good argument. 
> 
> You are right about that. I should rephrase that: "since it is implemented
> for two different targets, it may be a good starting point for the definition
> of an (L) interface" -- I think it is quite hard to even come up with some
> interface that is just abstract enough to be implementable by a wide range
> of targets and is at the same time low-level enough that it is still reasonably
> easy to implement.

But that is the gist of the discussion so far, if I am not mistaken. The 
lower the common API, the harder it is to define it.

That is why I proposed to craft an Object I/O interface which enables
programmers to write GUI application with a native look and feel albeit
with a reduced functionality (because not everything can be expressed with
the native set of UI elements). If the programmer is happy with this
functionality, fine - (s)he has a portable program with the native
look-and-feel. If not, then (s)he has to write non-portable code portions
for hToolkit, gtk2hs, a potential Aqua binding, or whatever backends
people provide. Only some backend specific code can guarantee that the
application is tailored to the platforms native look-and-feel when it 
comes to more difficult user interfaces.

> That certainly seems a good idea to me. Participation of many people with
> different backends is fairly essential as the (L) interface will probably
> change and evolve a lot when different backends are added. To get people 
> involved though, it may be good when the 'GUI task force' is able to define
> some initial (L) interface that people can try to write backends for.
Yes, but in my point of view this should be a medium level API like Object 
I/O, a bunch of IO function is doomed to be defined by the underlying 
backends. This certainly holds true for the Ports library.

I think Wolfgang will have a hard time making a sensible port of Ports to 
Aqua. The point is that the "common GUI" interface must enforce invariants 
such as "each application has exactly one menu bar" or "each pushbutton 
must have a text in it". Otherwise bindings to Aqua will not be possible.

You cannot define a common abstraction without looking at all the
implementations you have to do. I think we want three backends:  Win32,
Gtk and Aqua. So we need to look at all of them before we define the
interface.

Axel.