--- Axel Simon <A.Simon@ukc.ac.uk> wrote:
Hi Krasimir,
In the last two years I have implemented a binding of Gtk Version 2 to Haskell. I read the first paper about Object I/O of Peter Achten and Simon PJ which was published in IFL'00. I wondered if I could supply a layer like that of Object I/O to my library to get away from the raw monadic feeling whenever possible. I don't know how far you got to use Gtk but I assume there are mayor obstacles in creating a native interface to Windows and Gtk at the same time. Since I managed to get my binding running on Windows recently (no MSI installer yet), I thought it could be worthwhile considering Gtk as a single backend to Object I/O.
Could you give me some hints as if that is useful/possible? Also references to the most relevant papers would be good to get me started.
Thank you in advance, Axel.
Dear Axel, The Object I/O development is currently frozen. The native Win32 backend works but maybe still have bugs. I still support the library but only for bugfixes. I tried develop GTK backend for Object I/O but I found many difficulties. The main trouble is that the original Clean library are developed only for Windows. I think that Object I/O must be rewriten from scratch to make it more portable. For that reason I started my new project HToolkit (http://sourceforge.net/projects/htoolkit). The project maintain both GTK and native Win32 API. The library are separated in two levels. The low level is written in C and has two versions: for Win32 and for GTK. I think that the low level part are mostly completed (about 80-90% of GUI related Win32 and GTK API). The last week Daan Leijen started development of Port library. This is very thin Haskell layer over the low level C part. The idea is to make it reusable in other high level GUI libraries. After its completion I will retarget HToolkit to use Port. I hope that for the feature the Port will be ported to Mac platform. I think that for the time being developers which want to use Haskell for development of large scale projects are a trouble. There are nine known GUI libraries: * Gtk+HS * iHaskell * Gtk2HS * HTk * TclHaskell * Fudgets * FranTk * Object I/O * Yahu None of them are capable for large scale development for some reason. The HTk, TclHaskell, FranTk and Yahu are based on Tcl/Tk. The Tcl/Tk backend are portable but slow. The Gtk+HS, iHaskell, Gtk2HS are based on GTK. The backend is powerful and portable (GTK >= 2.0) but I prefer to use just native libraries on different platforms. The Object I/O is Win32 specific. I think that there are need of one portable and efficient library. It needs to have advantages of existing library but must have single uniform interface. I post this message to haskell@haskell.org because I think that development of nice libraries requires agreement of the entire Haskell Community on basic design lines. I looking for peoples which are interested in the development of "standard" GUI library. Best regards, Krasimir __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Hi folks, when I first asked Manuel (author of gtk+hs) if it is ok to make my Gtk binding public, he said something along the lines of "I can't keep you from making it public" and "I am not going to stop gtk+hs because of this". So it seems we are all waiting for the critical user mass that makes our own beloved GUI library (binding) the standard GUI library. For the sake of Haskell, we can only hope that this will actually happen one day. A sad side-effects of this is that most of us GUI developers waste a tremendous amount of time. A paper is just not worth the effort we put in writing the code. More to the point: On Fri, Jan 17, 2003 at 01:34:59AM -0800, Krasimir Angelov wrote:
Dear Axel,
The Object I/O development is currently frozen. The native Win32 backend works but maybe still have bugs. I still support the library but only for bugfixes. I tried develop GTK backend for Object I/O but I found many difficulties. The main trouble is that the original Clean library are developed only for Windows. I think that Object I/O must be rewriten from scratch to make it more portable.
Up to here it sounded quite encouraging. My Gtk2 programs seem to be very stable on Windows and - with careful design of the GUI - applications will behave and look very similar to MFC applications IMHO. Thus I thought that providing a known higher level layer similar to Object I/O would serve the needs of most people who would like to build applications with GUIs. Using the Object I/O techniques could attract those who have used this library before. Of course, this layer on top of Gtk2hs would be new and incompatible, simply because Gtk is so much different from Win32 when it comes to high level GUI objects.
For that reason I started my new project HToolkit (http://sourceforge.net/projects/htoolkit). The project maintain both GTK and native Win32 API. The library are separated in two levels. The low level is written in C and has two versions: for Win32 and for GTK. I think that the low level part are mostly completed (about 80-90% of GUI related Win32 and GTK API). ...
The last week Daan Leijen started development of Port library. This is very thin Haskell layer over the low level C part. The idea is to make it reusable in other high level GUI libraries. Another library which is possibly portable (sorry)? Could you elaborate Daan?
After its completion I will retarget HToolkit to use Port. I hope that for the feature the Port will be ported to Mac platform.
I am tempted to claim that a library which tries to use only native high-level API functions is doomed to behave slightly different on the various platforms (I heard that from Java). Furthermore, trying to unify several APIs sounds like taking the intersection which in turn reduces the functionality. I know that exactly this was proposed some years ago as a basic GUI library for Haskell, but I personally doubt that a restricted but portable GUI library serves anybody.
I think that for the time being developers which want to use Haskell for development of large scale projects are a trouble. There are nine known GUI libraries:
* Gtk+HS * iHaskell * Gtk2HS * HTk * TclHaskell * Fudgets * FranTk * Object I/O * Yahu
None of them are capable for large scale development for some reason. I might convert gtk2hs to the hierarchical module system which would break code. After that we only need to add bits here and there. A production-quality version 1.0 will be available this summer (That is the plan anyway).
The HTk, TclHaskell, FranTk and Yahu are based on Tcl/Tk. The Tcl/Tk backend are portable but slow. The Gtk+HS, iHaskell, Gtk2HS are based on GTK. The backend is powerful and portable (GTK >= 2.0) but I prefer to use just native libraries on different platforms. I guess I should say "me too". But being portable is more important for the success of Haskell as a language.
The Object I/O is Win32 specific. I think that there is a need of one portable and efficient library. I hope we all agree to this.
I post this message to haskell@haskell.org because I think that development of nice libraries requires agreement of the entire Haskell Community on basic design lines. Good idea.
Agreement is nice, but we cannot ask the community to vote for one library and therewith force people to abandon their GUI projects. Each of us can only hope that the very own GUI library becomes the de-facto standard.
I am looking for people which are interested in the development of a "standard" GUI library. Two answers: "Me too." and "I am.". But how can we proceed from here?
I think we should all be more flexible and communicate more openly and earlier. The latter probably would have avoided that I went off and did my own Gtk binding. Axel.
On Fri, 17 Jan 2003 15:12:55 +0000 Axel Simon <A.Simon@ukc.ac.uk> wrote:
Two answers: "Me too." and "I am.". But how can we proceed from here?
I think we should all be more flexible and communicate more openly and earlier. The latter probably would have avoided that I went off and did my own Gtk binding.
I am reading a lot of stuff regarding high level functional GUIs. It seems to me that the most fascinating ideas come from FRAN, which develops a model of continuous signals (and this is really rare in a GUI system, though useful) and of discrete events. Besides, representing GUIs as arrows is well-studied in FRAN, and also there is an algebra of behaviours and events (IE: given two events A and B, which produce the same type of signal, one can for example create the event (A or B) with a pure function returning a signal). Programming with FRAN is very similar to the design of a circuit. The Port library seemed to me (absolutely not to offend Manuel) a little more primitive. Anyway, I need still to fully understand arrows, and to study objectIO; In march/april I need to take a thesis to graduate, and it will probably be about effects systems; my idea is that with an effect system, wich needs to be simulated in Haskell (this is an argument for the Haskell mailing list) one could have a true model-view-presenter GUI program: the view, for example, would be bound to graphics-related side effects. Another point of interest for a functional GUI is the newcoming .NET interest. .NET already has three implementations, and it seems to me that verifyable bytecode would be a good starting point to implement an effect system. I hope that we all will take time to investigate what we really want and what we really can obtain from an Haskell GUI toolkit, and that there will be some feature that will make this system more interesting than, say, C# for quality software production. Vincenzo -- Teatri vuoti e inutili potrebbero affollarsi se tu ti proponessi di recitare te [CCCP]
On Fri, 17 Jan 2003 21:12:51 +0100 Nick Name <nick.name@inwind.it> wrote:
(this is an argument for the Haskell mailing list)
I didn't notice that this discussion wasn't already on the haskell mailing list, and tought that it was on gtk2hs, in case someone is wondering :) Vincenzo
Axel Simon <A.Simon@ukc.ac.uk> wrote,
when I first asked Manuel (author of gtk+hs) if it is ok to make my Gtk binding public, he said something along the lines of "I can't keep you from making it public" and "I am not going to stop gtk+hs because of this".
Just for the record, what I said is that I have neither intention nor right to keep you from making it public. More code is a Good Thing.
So it seems we are all waiting for the critical user mass that makes our own beloved GUI library (binding) the standard GUI library. For the sake of Haskell, we can only hope that this will actually happen one day. A sad side-effects of this is that most of us GUI developers waste a tremendous amount of time.
While a graphics library supported on all Haskell systems and running on all platforms is useful, having a whole spectrum of libraries available is the standard mode of operation in almost all programming languages. Any standardised graphics library will be a compromise that is usable only for relatively simple GUIs. Having said this, we started on a standard library a while ago, but not much progress has been made. For details, see http://haskell.org/communities/11-2001/html/report.html#sect4.3.1 Feel free to subscribe to gui@haskell.org and to revive the discussion. This btw is a good moment to take this thread of the main list to gui@haskell.org Cheers, Manuel
participants (4)
-
Axel Simon -
Krasimir Angelov -
Manuel M T Chakravarty -
Nick Name