| > What User Interface Library would you recommend for use under Windows? | | Unfortunately, there is no official GUI library for Haskell yet (but many | people are working toward this goal at the haskell gui mailing list). | ... | | Fortunately though, people are working on a good portable GUI solution for Haskell so | I expect that over a few months the situation will be better. Actually things seem to have gone a bit quiet, after a flurry. It seems to me that the way things usually make progress is if * a small group * writes a specification and then to put it out for comment to the wider community. Looking at the email, a plausible group seems to be Axel Simon (scribe) Daan Leijen Krasimir Angelov Sven Panne Peter Aachten John Meacham Any such group needs a scribe to write the first draft, and Axel seems to have started doing that already, hence my suggested 'scribe' attribution. I'm making this suggestion as an Aunt Sally to try to keep the momentum you guys have built up. Maybe some of you don't want to do this. Maybe others would like to be in the drafting group (Manuel, Wolfgang, etc). Maybe someone else should be scribe. But I do think that there should be a group of around 6 who roll up their sleeves and WRITE a specification. (Of course, such a specification will be heavily informed by implementations we already have, and should preferably be accompanied by one or more implementations so people can try it out.) There's been enough discussion that I *think* you agree about the broad outlines. It's just a question of crystallising the result. And it would be of real benefit to achieve that result. Simon
On Mon, Mar 03, 2003 at 03:52:03PM -0000, Simon Peyton-Jones wrote:
It seems to me that the way things usually make progress is if
* a small group * writes a specification
and then to put it out for comment to the wider community. Looking at the email, a plausible group seems to be Axel Simon (scribe) Daan Leijen Krasimir Angelov Sven Panne Peter Aachten John Meacham
Any such group needs a scribe to write the first draft, and Axel seems to have started doing that already, hence my suggested 'scribe' attribution.
I've been busy lately but I'll update the document with a new mission statement which we can agree upon. I would like to ask Daan to propose the outline of the core, i.e. set/get functions and how type classes fit in. Sorry for the delay, Axel.
I am actually between jobs right now so have quite a bit of time to help work on such a specification. If anyone hasn't seen it, there have been several more additions to my haskell GUI examples page: http://repetae.net/john/computer/haskell/gui/ John -- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john@foo.net ---------------------------------------------------------------------------
--- Simon Peyton-Jones
and then to put it out for comment to the wider community. Looking at the email, a plausible group seems to be Axel Simon (scribe) Daan Leijen Krasimir Angelov Sven Panne Peter Aachten John Meacham
I am still interested in GUI development and would like to continue discussion. Unfortunately the two weeks except the last three days I was in the hospital and probably I will continue to lie in hospital in the next one or two weeks. I hope that after that I will be in good repair to continue discussion. Best wishes, Krasimir __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/
Hi all,
It seems to me that the way things usually make progress is if
* a small group * writes a specification
I also believe that a small group would be good to get things started or otherwise there will be too much talking and too little working :-) However, I am currently wrapping up my thesis and will be too busy in March to contribute. Afterwards (April), I can do my share of work. Having said that, I would also like to express my doubts about the suitability of a common GUI specification -- I know, this is rather strange as I have been one of the main advocates for a portable API! I think that if we try to specify a full-fledged GUI API, it will be too much work to implement it on different backends. The API will be implemented partially, with bugs, misinterpreted, or not maintained. As examples of items that would make the implementations difficult are portable resource files, tool tips, tool bars, generic tree controls (on GTK), dockable windows, HTML (and openGL) rendering controls etc. Most are needed in larger applications and the lack of these items is one of the reasons that only toy apps. are written these days. Some people on this list think that we do have the resources to implement this all by ourselves, but I disagree -- portable toolkits like wxWindows and Qt have been in the works for years and with lots more development resources behind it, and even they have trouble supporting most platforms satisfactory. In my opinion, a common GUI specification only makes sense if we restrict ourselves to a simple API that supports simple (medium sized) GUI applications. A common denominator that is implementable with a reasonable amount of effort on many backends -- a bit like GIO and the current ObjectIO library. It would be good to have it, as it would create some order in the chaos of all the GUI bindings that are around now and give the user some hope of transferring applications easily between backends and platforms. On the other hand, it would always be a 'toy' API -- suitable for education and medium-sized applications (but I think that is the best we can do with such an API). My main point is that we should be more clear about the goals of the API as I feel that many discussions are just because of people having different goals in mind -- like the whole resource issue. All the best, Daan. ---- Another approach (that I favor) is to build a full fledged API on top of an existing full fledged library that is portable among all platforms. Libraries that come in mind are Java AWT, Tcl/Tk, Qt, and wxWindows. If Haskell is integrated with such library, it supports all gadgets you can ever wish and a Haskell developer will be on equal footage (is this english?) as C or Java programmer. Other "little" languages have chosen this approach too, wxPython and PythonTk are big examples, but we also have wxPerl, wxEiffel and Tcl itself. (Note that this approach doesn't preclude a common GUI API: the library will just expose more functionality.) One may worry that it is too much work to interface to these large systems (as the haskell GTK binding has proved), but in the end I think it is less work than trying to duplicate their efforts in Haskell. This is my main worry with the GIO/Port library: it is just a lot of work to maintain different backends and as soon as someone loses interest... I think that in some sense, the same happened to the Clean ObjectIO library, started out on the Mac, than Windows and now only windows is supported. (But it does show how useful it is to have at least some standard medium level GUI around!)
At 11:40 6-3-03 +0100, Daan Leijen wrote:
Hi all,
It seems to me that the way things usually make progress is if
* a small group * writes a specification I think this a good way to make progress, and I am willing to help with it. I would like to note that I do not have as much time available as some other people on this list seem to have, so one should not expect any implementation effort from my side.
Having said that, I would also like to express my doubts about the suitability of a common GUI specification -- I know, this is rather strange as I have been one of the main advocates for a portable API!
I think that if we try to specify a full-fledged GUI API, it will be too much work to implement it on different backends. The API will be implemented partially, with bugs, misinterpreted, or not maintained. As examples of items that would make the implementations difficult are portable resource files, tool tips, tool bars, generic tree controls (on GTK), dockable windows, HTML (and openGL) rendering controls etc. Most are needed in larger applications and the lack of these items is one of the reasons that only toy apps. are written these days. Some people on this list think that we do have the resources to implement this all by ourselves, but I disagree -- portable toolkits like wxWindows and Qt have been in the works for years and with lots more development resources behind it, and even they have trouble supporting most platforms satisfactory.
In my opinion, a common GUI specification only makes sense if we restrict ourselves to a simple API that supports simple (medium sized) GUI applications. A common denominator that is implementable with a reasonable amount of effort on many backends -- a bit like GIO and the current ObjectIO library. It would be good to have it, as it would create some order in the chaos of all the GUI bindings that are around now and give the user some hope of transferring applications easily between backends and platforms. On the other hand, it would always be a 'toy' API -- suitable for education and medium-sized applications (but I think that is the best we can do with such an API). I agree with Daan about the potential problems, and I would like to emphasize that it is easy to underestimate the maintainance effort of any GUI library. In contrast with Daan, I think this is the main reason why
Daan Leijen continues: this project should go for a portable API: it must be an open-ended, easily extensible GUI library with initial support for medium sized GUI applications. I think functional languages offer good tools to make this work. If such an API can't be made, then one might as well link in with an existing library.
Another approach (that I favor) is to build a full fledged API on top of an existing full fledged library that is portable among all platforms. Libraries that come in mind are Java AWT, Tcl/Tk, Qt, and wxWindows. If Haskell is integrated with such library, it supports all gadgets you can ever wish and a Haskell developer will be on equal footage (is this english?) as C or Java programmer. Other "little" languages have chosen this approach too, wxPython and PythonTk are big examples, but we also have wxPerl, wxEiffel and Tcl itself. (Note that this approach doesn't preclude a common GUI API: the library will just expose more functionality.) A point here is that the (full-fledged) functional API still needs to be designed unless one chooses a real thin interface layer. Such a solution would not profit from the expressiveness of a functional language, and should therefore only be chosen if no better solution can be found or agreed upon.
One may worry that it is too much work to interface to these large systems (as the haskell GTK binding has proved), but in the end I think it is less work than trying to duplicate their efforts in Haskell. This is my main worry with the GIO/Port library: it is just a lot of work to maintain different backends and as soon as someone loses interest... In summary: this project should yield a good functional design for a GUI API that is open-ended, and initially includes a (very) limited set of GUI elements (to encourage developers for making ports to their favourite platforms). However, in a sense this set should be 'arbitrary': they might as well have been included afterwards as 'plug-in's. No hardcoded prefab objects.
Note that this still allows a 'port' to a library that is portable on different platforms. If one can bear the "almost, but not quite, entirely unlike" platform look-and-feel, then that is OK.
I think that in some sense, the same happened to the Clean ObjectIO library, started out on the Mac, than Windows and now only windows is supported. (But it does show how useful it is to have at least some standard medium level GUI around!) The Clean GUI project started on the Mac, and portable implementations for an early version have been made for Windows and X Windows (relying on OpenLook). This was the 0.8 version, named Clean Event I/O. The project had a significant redesign to version 1.x - and was renamed into Object I/O -. For this version there is a leading port to the Windows platform and we are working on a Mac port.
Peter Achten
participants (6)
-
Axel Simon -
Daan Leijen -
John Meacham -
Krasimir Angelov -
Peter Achten -
Simon Peyton-Jones