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

[seth@cql.com]

I'd like to point out that it is quite possible to develop an interface at the
desired level (I agree that the gtk level is too low for many purposes) without
sacrificing functionality.

The way to achieve this magic is this:  Design your API at the optimal level
which, as Daan and others have stated, implies reduced functionality (compared
to wrapping the entire native API, for example).

Having defined this interface, it is quite possible to add lower level hooks. 
Care is necessary to see that these hooks are interoperable with the higher
level API (this is nontrivial but quite possible).  For most projects the
"standard" API would be adequate, and a program written with only the standard
API is portable.  For those cases where the reduced functionality of the
standard interface is not acceptable, lowever level capabilities can be used. 
This implies that either (1) portability is lost or (2) the developer must
implement the lower level functionality for all target platforms.

This paradigm is also good for the toolkit developers.  They must conform to
the standard interface, but they aren't prohibited from providing functionality
beyond the standard interface.

On 27-Jan-2003 Axel Simon wrote:
> 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.
> 
> _______________________________________________
> GUI mailing list
> GUI@haskell.org
> http://www.haskell.org/mailman/listinfo/gui

----------------------------------
Seth Kurtzberg
M. I. S. Corp.
E-Mail: seth@cql.com
Date: 27-Jan-2003
Time: 03:53:33

This message was sent by XFMail
----------------------------------