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

Axel Simon A.Simon@ukc.ac.uk
Mon, 27 Jan 2003 10:38:57 +0000


On Mon, Jan 27, 2003 at 12:21:07AM +0100, Daan Leijen wrote:
> 
> Axel wrote:
> 
> > 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
> 
> I am also in favor of a medium level GUI interface. If I gave another
> impression, that is my fault. 
Well, Ports is very low level like gtk2hs, since it is merely a wrapper 
around the C functions of HToolkit.

> > 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.
> 
> The (Clean) ObjectIO library actually consists of two layers, an (A) 
> and (L) part. Given their success, this proves that is certainly possible
> to define a decent (L) layer, on top of which a medium level API is built.
We are aiming for a platform-independent solution. Clean's library seems 
to be quite complete which is the reason why people could write an IDE in 
it. The fact that it started on MacOS 8 and 9 once upon a time and was 
then converted to Windows doesn't make it portable: The Mac backend is 
broken and there is no Unix backend at all. Peter Achten may prove me 
wrong here, but if the Clean low level layer (L) which is written in C was 
portable, why don't we use that layer directly? Why did Krasismir start 
with HToolkit?
IMHO it is easier to find a common API on the Object I/O level (A) not on 
the lower level.

> Actually, Port is closely modelled after the low-level object IO interface.
> The "low-level" is not so low-level as you may think. It is rather the 
> core medium-level functionality without any utility functions or abstractions.
>
> Again, I feel that we actually agree on all this topics. I am not a native
> speaker, so it may be that I am not always using the right words for 
> expressing myself. Sorry for that, but I am doing my best :-)
No prob. I hope I make myself reasonably clear. I think we agree on:
We want a GUI API specification which can be realized on all of the major 
platforms without sacrificing the native conventions. The latter implies 
that the API will only have a reduced functionality, but we can live with 
that.

> Maybe more knowledgeable people about UI's will come up with a much
> better interface than Port provides -- and that would be great!
> Maybe others have the knowledge or man-power to define a medium level
> GUI directly for multiple platforms. However, till that moment, we might
> be better off trying to work with resources that we have, and use an
> evolutionary approach to building a portable GUI library.
Here is were we disagree :-)

I do not like the evolutionary approach. It will lead to an API which 
changes a lot. If we'd start off with the core Object I/O library and add 
functions/datatypes incrementally by democratic vote (all backend 
implementors agree), we can have a more stable API. It would be clear what 
has been done and what needs to be done. It would further enable people 
earlier to use this library, and it would enable people to use the 
backends directly and gradually convert their applications to the common 
API.

Beyond that, I don't think I can make a reasonable interface to Ports from
gtk2hs as it seems very low-level to me. You say it's not, so I will have
to have a more thorough look. The reason I would like to fit my binding to
the common GUI API is that
- I don't want to bin the 13k+ lines of code we've written (which is 3 
times as much as the HToolkit) (ok, my personal reason)
- people should have a chance to write powerful GUI applications right 
now, and it might take years until the common API has stabilized

And the reason I'd like to have (A) as the common layer is:
- We could both put an Object I/O layer on top of our libraries. If we use 
the same core functionality, it would enable people to easily migrate 
their applications from one specific backend to the common API.

What do you think?
Axel.