The discussion has focused so far somewhat on implementation routes. My hope is that (A) we can define programming interface (i.e. a collection of abstract types and functions) (B) that is rich enough to be useful for writing GUI applications (C) and yet can be mapped onto a variety of architectures and toolkits If this were possible, then one could reduce effort in step (C) by using a toolkit (e.g. Gtk) that is already ported to multiple architectures, at the cost of look-and-feel; or, one could maintain look-and-feel compatibility by investing more in (C), so that the mapping was more native-aware. Regardless of which approach an implementor took, the application writer would still use interface (A). The question is: what should (A) look like? Is it even possible to define a rich enough (A) without making (C) impossible? The answer to the latter question must surely be "yes, provided one is not too ambitious with (A)". Peter Aachten goes further. Based on the Clean group's experience, he thinks we can not only define a satisfactory (A), but also define a lower-level interface (expressed in the C language) that suffices to support (A) and yet contains no target specific code That would be even better, because then lots of the implementation of (A) becomes shared between many targets. The Clean experience is that the code sharing is substantial. So I ask: what are the candidates for (A)? I've suggested one: the Clean Object-IO model, or something related (the MVar vs local state question is still open). Are there any other proposals? Simon
--- Simon Peyton-Jones
(A) we can define programming interface (i.e. a collection of abstract types and functions) What library level do you propose? Low level or middle level (as ObjectIO)? I prefer to fist define simple low level interface and after that write middle or high level library like ObjectIO.
Krasimir __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
I've had a look at the Port library, and I think I like it. It looks as if it won't be too difficult to port it to Mac OS X - I'll see what I can do to make it happen. Of course, there's the ever-present menu bar issue (on Mac OS, a menu bar is associated with an application, not with a window). I'll try to work around that somehow. Are there some simple example programs implemented using the Port library that I could use for testing my implementation? I've got some exams coming up in the next two weeks, so I don't know how much time I'll really have, so don't expect results too soon. Cheers, Wolfgang
Dear Wolfgang,
Are there some simple example programs implemented using the Port library that I could use for testing my implementation?
I have put the GIO library on the htoolkit sourceforge cvs. The library is not nearly complete or anything, but it uses Port and contains a bunch of simple example programs. Thanks for your support, Daan.
Simon, On Fri, Jan 24, 2003 at 01:11:02PM -0000, Simon Peyton-Jones wrote: [..]
My hope is that
(A) we can define programming interface (i.e. a collection of abstract types and functions)
(B) that is rich enough to be useful for writing GUI applications
(C) and yet can be mapped onto a variety of architectures and toolkits
[..]
The question is: what should (A) look like? Is it even possible to define a rich enough (A) without making (C) impossible? The answer to the latter question must surely be "yes, provided one is not too ambitious with (A)".
You mean "ambitious with (B)", I assume. Again, reducing (B) automatically means affecting the look-and-feel. But for me this is not a severe issue.
Peter Aachten goes further. Based on the Clean group's experience, he thinks we can not only define a satisfactory (A), but also define a lower-level interface (expressed in the C language) that suffices to support (A) and yet contains no target specific code No target specific code? I don't think I understand what you mean. The APIs are target specific. So where is the advantage of specifying the impedance matching code in C?
what are the candidates for (A)?
I've suggested one: the Clean Object-IO model, or something related (the MVar vs local state question is still open). Are there any other proposals? I am happy with Object I/O concept as a medium layer. But I am very suspicious about the intermediate layer. You said you would go for a GUI interface which is reduced but portable and I fear that it is a very time consuming effort to find this layer. I believe that there are many people right now who want to write GUI applications who I think we should serve.
A proposal: We start from different platforms: - we have an Object I/O library for Win32 in ghc's CVS - Gtk - A native Aqua interface could be started Can we extract the core infrastructure (no widgets) of Object I/O into a separate CommonGUI module which all these libraries use. We could then gradually define widget (and other) abstractions in the CommonGUI library and map them to all native libraries. Advantages: - People who want to do full fledged applications can do so right now using one of the native libraries. - In the long run, we will have a CommonGUI library which restricts itself to elements which can be implemented with the native look-and-feel. Any comments? Axel.
Dear Axel,
Can we extract the core infrastructure (no widgets) of Object I/O into a separate CommonGUI module which all these libraries use. [snip] - In the long run, we will have a CommonGUI library which restricts itself to elements which can be implemented with the native look-and-feel.
This is indeed exactly what we need! and except for the name, this is exactly what the Graphics.UI.Port library is trying to do. Fortunately for us, Krasimir has already done all the hard work and studied the whole off the GTK and Windows API and extracted a common interface (and I have little doubt that the Port interface will also work for Aqua). -- Daan.
_______________________________________________ GUI mailing list GUI@haskell.org http://www.haskell.org/mailman/listinfo/gui
On Fri, Jan 24, 2003 at 03:32:05PM +0100, Daan Leijen wrote:
- In the long run, we will have a CommonGUI library which restricts itself to elements which can be implemented with the native look-and-feel.
This is indeed exactly what we need! and except for the name, this is exactly what the Graphics.UI.Port library is trying to do. Fortunately for us, Krasimir has already done all the hard work and studied the whole off the GTK and Windows API and extracted a common interface (and I have little doubt that the Port interface will also work for Aqua). Dear Daan,
is my perception right that Krasimir has created the beginning of a portable GUI library in C and that you Ports library is the Haskell interface? If so, perhaps we could just add HToolkit to the possible back-ends: - Win32 Object I/O in CVS - Gtk(2hs) - an Aqua binding - HToolkit But the remaining issue is to create a common (probably Object I/O based) layer which gives a common, stable interface to all these. If Krasimir has done such a good job (and honestly, I do not doubt that), then your Ports library will be a 1:1 mapping to this CommonGUI library. But there are so many facettes to a GUI library that it will take years till everything is implemented. And till then we have the other libraries which people like Simon Marlow can use to implement specialized version of their 2&3 programs (recall: richt widget set and native look'n'feel). Axel.
Dear gui list members, The discussions on this list seem to diverge rather quickly. Most importantly for the Haskell community right now is the short-term availability of a *some* middle-ground portable gui library: worse is better. In the past months, Krasimir has worked very hard on creating a low-level portable C interface that is implemented for both GTK and Windows -- an amazing piece of work, thanks Krasimir! In the past weeks, I have put a small Haskell marshalling layer on top of the C interface -- the resulting library is called "Graphics.UI.Port" (and is available (and haddock documented) from the HToolkit sourceforge cvs.) Allthough it is not 'complete', the interface is already fairly substantial and I think it embodies a great *concrete* proposal for a low-level, portable GUI interface in Haskell. I really hope that people will give this a good look and I think we should seriously consider adapting this interface as the new standard low-level portable gui interface for Haskell. Haddock documentation can be viewed online at: http://www.cs.uu.nl/~daan/doc/port ------------ Furthermore, on top of the Port library, I have written a middle-ground GUI library to test the suitability of the Port interface. This library is called "Graphics.UI.GIO", for graphical IO. The name is not without reason, the library is middle-ground and all operations are still in the IO monad, there is no explicit structure for modelling state. The interface is extremely similar to Yahu and TkGofer (see http://www.cs.chalmers.se/Cs/Grundutb/Kurser/afp/yahu.html ) and I have attached some (working!) source code of the famous bouncing balls demo to give an impression. GIO is still just a skeleton and not yet public, but again, it may be the basis of a concrete proposal towards a middle ground GUI library. On top of this, people can build their own fancy interfaces, like FranTk, Fruit, or even ObjectIO. (see "Structuring graphical paradigms in TkGofer"). Haddock documentation can be viewed online at: http://www.cs.uu.nl/~daan/doc/gio All the best, Daan. ------------------ module Main where import Graphics.UI.GIO main = start balls balls = do vballs <- newVar [] w <- window [title =: "Bouncing balls", resizeable =: False, view =: sz maxX maxY] set w [ on paint =: paintBalls vballs , on click =: dropBall w vballs ] timer [interval =: 20, on command =: nextBalls w vballs] where nextBalls w vballs = do updateVar vballs (filter (not.null) . map (drop 1)) repaint w dropBall w vballs pt = do updateVar vballs (bouncing pt:) repaint w bouncing (Point x y) = map (\h -> Point x (maxH-h)) (bounce (maxH-y) 0) bounce h v | h <= 0 && v == 0 = [] | h <= 0 && v < 0 = bounce 0 ((-v)-2) | otherwise = h : bounce (h+v) (v-1) paintBalls vballs can updframe updareas = do box updframe [color =: lightgrey] can balls <- getVar vballs mapM_ (drawBall can) (map head (filter (not.null) balls)) drawBall can pt = do oval pt radius radius [color =: red] can ellipse pt radius radius [] can -- radius the ball, and the maximal x and y coordinates radius, maxX, maxY :: Int maxY = 300 maxX = 300 radius = 10 -- the max. height is at most max. y minus the radius of a ball. maxH :: Int maxH = maxY - radius
Daan, I didn't know about your code. I will definitely try it. Don't keep it a secret. :) On 24-Jan-2003 Daan Leijen wrote:
Dear gui list members,
The discussions on this list seem to diverge rather quickly. Most importantly for the Haskell community right now is the short-term availability of a *some* middle-ground portable gui library: worse is better.
In the past months, Krasimir has worked very hard on creating a low-level portable C interface that is implemented for both GTK and Windows -- an amazing piece of work, thanks Krasimir! In the past weeks, I have put a small Haskell marshalling layer on top of the C interface -- the resulting library is called "Graphics.UI.Port" (and is available (and haddock documented) from the HToolkit sourceforge cvs.)
Allthough it is not 'complete', the interface is already fairly substantial and I think it embodies a great *concrete* proposal for a low-level, portable GUI interface in Haskell. I really hope that people will give this a good look and I think we should seriously consider adapting this interface as the new standard low-level portable gui interface for Haskell.
Haddock documentation can be viewed online at: http://www.cs.uu.nl/~daan/doc/port
------------ Furthermore, on top of the Port library, I have written a middle-ground GUI library to test the suitability of the Port interface. This library is called "Graphics.UI.GIO", for graphical IO. The name is not without reason, the library is middle-ground and all operations are still in the IO monad, there is no explicit structure for modelling state.
The interface is extremely similar to Yahu and TkGofer (see http://www.cs.chalmers.se/Cs/Grundutb/Kurser/afp/yahu.html ) and I have attached some (working!) source code of the famous bouncing balls demo to give an impression.
GIO is still just a skeleton and not yet public, but again, it may be the basis of a concrete proposal towards a middle ground GUI library. On top of this, people can build their own fancy interfaces, like FranTk, Fruit, or even ObjectIO. (see "Structuring graphical paradigms in TkGofer").
Haddock documentation can be viewed online at: http://www.cs.uu.nl/~daan/doc/gio
All the best, Daan.
------------------ module Main where
import Graphics.UI.GIO
main = start balls
balls = do vballs <- newVar [] w <- window [title =: "Bouncing balls", resizeable =: False, view =: sz maxX maxY] set w [ on paint =: paintBalls vballs , on click =: dropBall w vballs ] timer [interval =: 20, on command =: nextBalls w vballs] where nextBalls w vballs = do updateVar vballs (filter (not.null) . map (drop 1)) repaint w
dropBall w vballs pt = do updateVar vballs (bouncing pt:) repaint w
bouncing (Point x y) = map (\h -> Point x (maxH-h)) (bounce (maxH-y) 0)
bounce h v | h <= 0 && v == 0 = [] | h <= 0 && v < 0 = bounce 0 ((-v)-2) | otherwise = h : bounce (h+v) (v-1)
paintBalls vballs can updframe updareas = do box updframe [color =: lightgrey] can balls <- getVar vballs mapM_ (drawBall can) (map head (filter (not.null) balls))
drawBall can pt = do oval pt radius radius [color =: red] can ellipse pt radius radius [] can
-- radius the ball, and the maximal x and y coordinates radius, maxX, maxY :: Int maxY = 300 maxX = 300 radius = 10
-- the max. height is at most max. y minus the radius of a ball. maxH :: Int maxH = maxY - radius
_______________________________________________ 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: 24-Jan-2003 Time: 09:39:34 This message was sent by XFMail ----------------------------------
On Friday 24 January 2003 13:11, Simon Peyton-Jones wrote:
Peter Aachten goes further. Based on the Clean group's experience, he thinks we can not only define a satisfactory (A), but also define a lower-level interface (expressed in the C language) that suffices to support (A) and yet contains no target specific code
I don't really understand this, so a couple of questions if I may.. 1- What does this low level code do that requires it to be written in C? I can't think of any particular reason for this other than speed, and I can't think of anywhere a gui really needs speed other than for rendering. (But that can't be so because, as everybody keeps telling me, writing our own portable rendering code is a really bad idea :-) 2- If I'm not missing something, there must be some target specific code somewhere in any port of a portable library. Is this, dare I suggest, in an even lower level of primitives? Thanks -- Adrian Hey
Adrian, Experience with Java shows that efficiency is, indeed, important in a GUI layer. Not to say it can't be done in Haskell (and not to say that it necessarily can); to say that efficiency is unimportant is not an option. On 24-Jan-2003 Adrian Hey wrote:
On Friday 24 January 2003 13:11, Simon Peyton-Jones wrote:
Peter Aachten goes further. Based on the Clean group's experience, he thinks we can not only define a satisfactory (A), but also define a lower-level interface (expressed in the C language) that suffices to support (A) and yet contains no target specific code
I don't really understand this, so a couple of questions if I may..
1- What does this low level code do that requires it to be written in C? I can't think of any particular reason for this other than speed, and I can't think of anywhere a gui really needs speed other than for rendering. (But that can't be so because, as everybody keeps telling me, writing our own portable rendering code is a really bad idea :-)
2- If I'm not missing something, there must be some target specific code somewhere in any port of a portable library. Is this, dare I suggest, in an even lower level of primitives?
Thanks -- Adrian Hey
_______________________________________________ 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: 24-Jan-2003 Time: 09:38:29 This message was sent by XFMail ----------------------------------
On Friday, 2003-01-24, 16:22, CET, Adrian Hey wrote:
[...]
1- What does this low level code do that requires it to be written in C? I can't think of any particular reason for this other than speed, and I can't think of anywhere a gui really needs speed other than for rendering. (But that can't be so because, as everybody keeps telling me, writing our own portable rendering code is a really bad idea :-)
Hello, I think it is really good to provide the platform-independent imperative interface in C because this way it is also usable with other programming languages than Haskell. This results in more people interested in developing the interface and the underlying implementations. By the way, I'm heavily interested in such a C interface also as a basis for a platform-independent Ada library.
[...]
I'd like to add that I'm really impressed by the work Krasimir, Daan and maybe others have done in developing HToolkit. The approach of * developing a platform-independent C interface * implementing it on top of different native APIs * creating a thin Haskell binding to the C interface is exactly what I favor. I haven't a detailed picture of HToolkit yet but at least these three points are something I'd like to see in a future standard. I'd like to point out again that although the C interface shall be low level concerning programming style (i.e., it shall be imperative) it should be high level concerning the facilities it provides (e.g., it should provide complete file selection dialogs). As Peter Achten mentioned in his mail from 2003-01-24 11:48:32 +0100, abstraction is essential. Wolfgang
Wolfgang, No disagreement, but then we return to the question: why not use an existing toolkit such as gtk? Especially as there is an existing haskell interface to it from which a lot can be learned. On 25-Jan-2003 Wolfgang Jeltsch wrote:
On Friday, 2003-01-24, 16:22, CET, Adrian Hey wrote:
[...]
1- What does this low level code do that requires it to be written in C? I can't think of any particular reason for this other than speed, and I can't think of anywhere a gui really needs speed other than for rendering. (But that can't be so because, as everybody keeps telling me, writing our own portable rendering code is a really bad idea :-)
Hello,
I think it is really good to provide the platform-independent imperative interface in C because this way it is also usable with other programming languages than Haskell. This results in more people interested in developing the interface and the underlying implementations. By the way, I'm heavily interested in such a C interface also as a basis for a platform-independent Ada library.
[...]
I'd like to add that I'm really impressed by the work Krasimir, Daan and maybe others have done in developing HToolkit. The approach of * developing a platform-independent C interface * implementing it on top of different native APIs * creating a thin Haskell binding to the C interface is exactly what I favor. I haven't a detailed picture of HToolkit yet but at least these three points are something I'd like to see in a future standard.
I'd like to point out again that although the C interface shall be low level concerning programming style (i.e., it shall be imperative) it should be high level concerning the facilities it provides (e.g., it should provide complete file selection dialogs). As Peter Achten mentioned in his mail from 2003-01-24 11:48:32 +0100, abstraction is essential.
Wolfgang _______________________________________________ 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: 24-Jan-2003 Time: 22:57:56 This message was sent by XFMail ----------------------------------
On Saturday, 2003-01-25, 06:58, CET, seth@cql.com wrote:
Wolfgang,
No disagreement, but then we return to the question: why not use an existing toolkit such as gtk? Especially as there is an existing haskell interface to it from which a lot can be learned.
I never meant not to use an existing toolkit. In fact, I always meant that we should use existing "native" toolkits/libraries in order to achieve platform look-and-feel etc. Because for POSIX I see the available desktop environments as platforms, I would prefer a GTK+/GNOME implementation instead of just a GTK+ implementation but to get a working solution a GTK+ implementation is o.k. What we cannot do with the HToolkit approach is to reuse one of the existing Haskell GTK+ bindings since the C interface we bind to has to be already platfrom-independent. But of course, it can be learned from them. By the way, the approach of doing the platform-dependent stuff completely outside Haskell and providing a platform-independent interface in C has another advantage. Since most programming languages can export C functions, this approach allows as to also implement our GUI stuff on top of a non-C library/toolkit. We could for instance write C++ code which is based on Qt and the KDE libraries and exports our standardized platform-independent C functions.
[...]
Wolfgang
On Sat, 25 Jan 2003 11:57:05 +0100
Wolfgang Jeltsch
I never meant not to use an existing toolkit. In fact, I always meant that we should use existing "native" toolkits/libraries in order to achieve platform look-and-feel etc.
I am not sure to have understood what's going on. If there is a C backend yet to be written, on top of wich implement an Haskell layer, why not reuse the unix part, writing just a native backend for gtk2/win32? It would reuse a lot of code, and would simultaneously solve a big problem for the many gtk apps out there, written in various languages: having a reasonable look on windows (and the same idea holds for quartz, too). Indeed, it would solve the problem of writing the C backend for linux and bsd, too. I know that many people, reading this, will just think "no, rewriting our C lowlevel library is easier because it will exacly fit our needs" but, believe, it's just the not-done-by-myself syndrome already mentioned on this list :) I don't think that designing a C backend for an UI will look (from the programmer's point of view) different from gtk. BTW, I think that this backend can be comfortably written in haskell, since there is a binding for win32 and one for gtk, we could just abstract etc etc. In fact, If I had to bet on what will happen in the next two years, I would surely bet on objectIO implemented directly over the win32 API and over the gtk2 API, but there's no bookmaker here now :) Vincenzo -- Teatri vuoti e inutili potrebbero affollarsi se tu ti proponessi di recitare te [CCCP]
participants (9)
-
Adrian Hey -
Axel Simon -
Daan Leijen -
Krasimir Angelov -
Nick Name -
seth＠cql.com -
Simon Peyton-Jones -
Wolfgang Jeltsch -
Wolfgang Thaller