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