- GUI - Haskell.org

Haskell GUI examples
by George Russell 04 Mar '03

04 Mar '03

I took a few minutes (5) to implement the Haskell GUI example in HTk. Code attached. Forgive me for boasting but it seems clearer, simpler and shorter than any other of the examples codings on John Meacham's website. The closest competitor seems to be GIO. This code should work (I haven't tested it) on any of Windows, Linux, Solaris and FreeBSD, all of which we support. {- "Goodbye" demo as discussed on the Haskell mailing list. Specification: pops up a window saying "Hello World" and presenting a button saying "Bye". Clicking the button once changes the message to "Goodbye"; clicking it a second time causes the program to quit. -} module Main where import Computation import Events import HTk main = do mainWin <- initHTk [text "Hello World"] label <- newLabel mainWin [text "Hello World"] button <- newButton mainWin [text "Bye"] pack label [] pack button [] buttonClicked <- clicked button sync buttonClicked label # text "Goodbye" sync buttonClicked destroy mainWin

3 2

Re: [GUI] Mission Statement + Widgets
by David Sankel 04 Mar '03

04 Mar '03

Note: forwarded message attached.

1 0

RE: [GUI] Mission Statement
by Simon Peyton-Jones 04 Mar '03

04 Mar '03

Good start. I have one other suggestion: put the document in the CVS repository (haskell-report/gui, say. We already have haskell-report/report and haskell-report/ffi) That way participants can modify typos directly, add comments etc. Simon | -----Original Message----- | From: Axel Simon [mailto:A.Simon@ukc.ac.uk] | Sent: 03 March 2003 23:56 | To: gui(a)haskell.org | Subject: [GUI] Mission Statement | | Hi, | | I tried to formulate a Mission Statement and I invite people to review it. | It is Section 3 in the same document in which I gathered initial opinions: | | http://www.cs.ukc.ac.uk/people/staff/as49/poll.pdf | | It basically says what the Common GUI API is. In my opinion it would be | beneficial for us to agree on something like this statement. Otherwise I | fear people will restart discussions on topics for which we already | reached a consensus. | | Section 4 contains some comments from the GUI programmer perspective. | Comments on this are welcome as well. | | In the near future I will browse through the achieves and extract | opinions on the technical topics in Section 5. Before we agree on anything | there, I think it would be a good idea to agree on the core. Daan, is the | last version of the GIO core you posted what you propose as core? If so, I | will add it to the document for scrutinization. | | Thanks for comments, | Axel. | | _______________________________________________ | GUI mailing list | GUI(a)haskell.org | http://www.haskell.org/mailman/listinfo/gui

1 0

Example: Binding C++ to Haskell using the ffi
by David Sankel 02 Mar '03

02 Mar '03

Here is some example code doing just that. It uses ghc. Questions: Can one think of better ways to interface generic c++ libraries to Haskell? What do you think of the ->> member function operator? for the ffi people: Has any though gone into cplusplus? If so, how would it interface? Would stubs on the c++ side be generated or would it use the code directly. Later, David J. Sankel

4 4

Example: Binding C++ to Haskell using the ffi
by David Sankel 01 Mar '03

01 Mar '03

Sorry, forgot attachment . . . again. :-P -- Here is some example code doing just that. It uses ghc. Questions: Can one think of better ways to interface generic c++ libraries to Haskell? What do you think of the ->> member function operator? for the ffi people: Has any though gone into cplusplus? If so, how would it interface? Would stubs on the c++ side be generated or would it use the code directly. Later, David J. Sankel

1 0

Binding c++ gui libraries to haskell.
by David Sankel 27 Feb '03

27 Feb '03

Forgot attachment. -- This is an short example program that uses the ffi to bind an fltk (www.fltk.org) call to haskell. Please give me your Makefile changes if you needed to change it. I'd like to get this gui-haskell ball rolling some more. David J. Sankel

2 2

Binding c++ gui libraries to haskell.
by David Sankel 27 Feb '03

27 Feb '03

This is an short example program that uses the ffi to bind an fltk (www.fltk.org) call to haskell. Please give me your Makefile changes if you needed to change it. I'd like to get this gui-haskell ball rolling some more. David J. Sankel

1 0

I love GIO.
by Axel Simon 21 Feb '03

21 Feb '03

Good morning, I had a look at GIO and my first impression is that it's interface is nice for application writers as well as for GUI toolkit implementors. What appeals to me (having a low-level GUI binding, gtk2hs) is that binding to such an API is actually worthwhile (i.e. it's more than just renaming functions). Some questions, comments and critics about GIO: 1. Using IO (). All functions use the IO () monad unlike the proposed port of Object IO which introduces GUI (). I think this decision is the Right Thing (tm). (If other libraries insist of having their own Monad then it can become impossible to mix these two libraries.) 2. The := operator. The =: function should say "assign to this property". Is seems to be the wrong way round. Is it possible to use the constructor := , or is this conceptionally difficult? 3. The global mechanism to change widgets. The set and get functions define a single mechanism to modify UI components. This seems very neat to me. This is implemented via Haskell classes. The distribution between functions and classes seem to be a little ad-hoc, though. The two extremes are probably: a) Define a class for every function and make each widget which supports this function an instance of this class. Or b) define a class for every widget and make every function this widget has a member of this class. Why do you use this mixed approach (e.g. class Able, Select, SingleSelect,...)? 4. Educational vs Professional. When browsing the drawing primitives, I noticed that you abandon the explicit use of Pens (i.e. graphics contexts, GCs). GCs are used for performance reasons as passing color, thickness etc. each time is said to be inefficient. This is probably just one example begging the general question: Are we aiming for an API which is easy to use or which enables professional applications? It's the latter, right? So far, there is probably more to debate, but I have to get some work done :-), Axel.

6 16

RE: [GUI] Re: Gtk and Object I/O
by Simon Peyton-Jones 20 Feb '03

20 Feb '03

| > 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 phrased this badly. What I meant was this. Let's call the lower-level interface (L). Let's call the thing we are mapping to the "target". A target is either a portable library like GTK, or a native UI platform like Windows. A target is something we don't implement. The goals of (A) are: Reasonably easy for programmers to use Programmer's interface does not change across targets Rich enough to be useful The goals of (L) are Reasonably easy to implement (but maybe less easy to program with) Programmer's interface (from "above") does not change across targets Rich enough to implement (A) As I understand it: ObjectIO and Daan's Graphics.UI.GIO are examples of (A) Daan and Krasimir's Port is an example of (L) When I said "contains no target-specific" code, I meant that the code that implements (A) using (L) is not target specific. The implementation of (L) will certainly be target specific. You are right that (L) does not need to be written in C. Indeed there might be many implementations of (L): some which are entirely in Haskell (perhaps implemented by you), others written mostly in C (using existing libraries). I know little about particular UI libraries. My suggestion, though, is that we focus discussion on what (A) and (L) should look like, rather than on how they should be implemented. Simon

14 51

Fruit & Co
by George Russell 19 Feb '03

19 Feb '03

I have to say I'm very sceptical about things like Fruit which rely on reactive animation, ever since I set our students an exercise implementing a simple space-invaders game in such a system, and had no end of a job producing an example solution. Things like getting an alien spaceship to move slowly downwards, moving randomly to the left and right, and bouncing off the walls, turned out to be a major headache. Also I think I had to use "error" to get the message out to the outside world that the aliens had won. My suspicion is that reactive animation works very nicely for the examples constructed by reactive animation folk, but not for my examples. I wonder how you would do it? A translation of the exercise I set, without the hints we had to put in, is as follows: > Earth is being attacked by aliens! The aliens are flying triangular spaceships > downwards. At each moment a spaceship flies either left and down, or right and down, > or directly down. The directions change at random, except that a spaceship may not > leave the window. Against them stands only a (rectangular) gun, driven with > the mouse. When the middle button is pressed, the lowest ship directly above is > destroyed. However should a ship reach the (horizontal, straight) ground, the war > is lost. Implement the following simulation function: > spaceInvaders :: Double -> IO () > The larger the Double is, the faster the spaceships should be.

2 1