March 2003 - GUI - Haskell.org

Mission Statement
by Axel Simon 07 Mar '03

07 Mar '03

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.

4 6

Common GUI API : What would the code look like?
by David Sankel 07 Mar '03

07 Mar '03

Overview :: This is an example of a low-level binding to a c++ GUI library and a mid-level abstraction over it. This was created primarily to spark discussion in the gui(a)haskell.org mailing list and secondarily to provide a simple example that can be compiled using ghc without any language extensions. I encourage those who code, to implement their ideas for the Common GUI API using this simple framework. This would allow all reviewers to understand exactly what you are talking about by running your examples. Fltk was chosen for its simplicity and portability. I didn't use an existing library because I wanted a short example where the source code is easy to comprehend at all levels. Questions :: 1) How does the interface look in Test_midlevel.hs? Is there any critiques in regard to using this style in CGA (Common GUI API)? 2) What drastic or minor changes would have to be made to the Test_midlevel.hs file to make it CGA compatible? Yes, this is a completely subjective question. In your opinion, what should Test_midlevel.hs look like? 3) There has been some discussion about using non-standard Haskell extensions in CGA. No extensions have been used in this example. Exactly what extensions would be useful in this example or in CGA as a imaginary whole? Is it worth it to use said extensions and allow CGA to be incompatible with Haskell98? 4) Haskell has one namespace, the global one. Since there would be a lot of function names and attributes in CGA, their names should be well thought out. Is there any initial ideas on how to handle this? 5) I am willing to implement more stuff like this. What other stuff would you like to see with this? Running :: To run the examples, one needs a standard Haskell compiler with ffi (ghc) and fltk installed (http://www.fltk.org) run make. If necessary, change the makefile to modify for your configuration. f_*_stub.cpp -- These are the stubs that are used to bind the c++ library to c functions. This is required because the Haskell ffi standard does not specify any conventions for C++. Fl.hs Box.hs Button.hs Window.hs -- These contain the bindings to the stub files. They also provide a low-level interface for the GUI toolkit. Test_lowlevel.hs -- This is a simple program demonstrating use of the low-level binding. Attributes.hs -- This code was taken from the htoolkit cvs server. Simple modifications were made to suit our purposes. A_Button.hs -- This is an abstraction over the low-level Button interface. It uses the Attributes module for the mid-level interface. Test_midlevel.hs -- This is the same simple program as Test_lowlevel.hs except it uses A_Button instead of Button to demonstrate use of the Attributes abstraction. Cheers, David J. Sankel

4 10

RE: GUI for Windows
by Simon Peyton-Jones 06 Mar '03

06 Mar '03

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

6 5

Re: [GUI] Mission Statement + Widgets
by Axel Simon 05 Mar '03

05 Mar '03

On Tue, Mar 04, 2003 at 12:57:48PM -0800, David Sankel wrote: > Hello, > > I would like to clarify my opinion. I would > strongly suggest to _not_ use Qt as a backend > primarily to license issues. I suggested using the Qt > feature-set as a goal feature-set. If there is somebody who wants to write a binding to Qt then that is not a problem. As far as I remember you were about the only one who endorsed Qt. As Simon said, we want to have a spec that is implementable. The only way to ensure this is to propose some functionality, implement it on all backends mentioned in the document and then mark it as stable when it worked out for all backends. That is the only reason I included the list of backends. If there is no one to write a binding to Qt right now, then Qt has to be removed from the list. That doesn't preclude writing a binding to backends not in the list. But such an effort will not influence the spec anymore. So if there are people out there who are willing to write backends for other platforms: now is the time to add them to the report. > I think that sound api should be of low priority > (aside from the simple windows asterix like sounds > when a dialogue pops up). I put sound and printing at the very bottom of the list which should mean they have a low priority. I can remove them if other people think this is out of scope but I sense that this effort is nothing that has a definite end but can go on for quite a long time. > Regarding GIO, I am very interested and it seems > like the way to go. I can't find it on the internet > though. Can someone give me a link so I may review > it? Search for GIO on sourceforge.net. > I would suggest putting aside the MDI SDI questions > for now, and work on defining a widget set. But we need to know how to set up a main window before we put any widgets in it, don't we? I can imagine that once we are past this stage, adding widgets will be quick and simple. I adjusted your comment on Qt. Thanks, Axel.

7 7

Some Discussion Topics
by Wolfgang Thaller 05 Mar '03

05 Mar '03

There seem to be several different discussions going on at the same time, all mixed up into one thread. Yet many of the topics we have to tackle are completely orthogonal to each other. I'll attempt to list a few that can and perhaps should be discussed separately, in no particular order: 1) How to create objects and how to get/set their attributes - the Haskell side of things 2) Laying out widgets 3) What widgets should be supported in the initial version 4) Graphics Drawing 5) What different kinds of Windows are there, and how do they behave? This is the MDI/SDI issue, phrased differently. From the top of my head, I can think of - document windows - modeless dialog windows, - application-modal dialog windows (and alert windows/message boxes) - window-modal dialog boxes (do they exist on any non-MacOS platform?) - utility windows (for toolbars etc.) - MDI frame windows (which don't exist on all platforms - an MDI frame should be created automatically when appropriate for MDI applications). 6) How should menu bars be laid out? We have to deal with different conventions of different platforms 7) How should keyboard shortcuts for menu commands and for other commands be handled? I guess that 1) one of the most important points. Number 5) is very important for providing native look-and-feel, and almost all existing cross-platform toolkits have done this at least slightly wrong by designing with only one platform in mind. I'm sure there are several more areas that will need discussion.... Cheers, Wolfgang

1 0

GIO and HTk
by George Russell 05 Mar '03

05 Mar '03

Daan wrote (snipped) > I am flattered but I still view GIO as an *experiment* to get a feel > of how a medium-level GUI API should look like, so it is not nearly > a competitor to a real library. Well OK. In that case I think HTk *does* qualify as a real library. It has been around for several years, is pretty stable, and can be used to write fairly complex GUI interfaces. Its web-page, by the way, is http://www.informatik.uni-bremen.de/htk However it is interesting that the look-and-feel of HTk and GUI are similar. This suggests that the general ideas of both are right. I'm not going to argue the details of syntax such as whether # should be in there or not. The main difference is that HTk uses events while GIO uses callbacks. In the HTk example I gave, buttonClicked is an event.

1 0

RE: [GUI] Mission Statement + Widgets
by Simon Peyton-Jones 05 Mar '03

05 Mar '03

| I further believe that the item of primary | importance is the user's haskell api. I could easily | write a backend using fltk, Qt, winapi, or whatever | and we'd probably see that once the specification is | finished. The sample implimentation that is released | with the gui-haskell standard need not work on three | platforms, but only one. Once it is released (if not | before) the other backends will come quickly. I | suggest efforts are concentrated on the actual | haskell-interface document as that will give the most | bang for the buck. Others can then impliment backends | according to their preferences (ncurses, CORBA, COM, | odbc?). Yes, yes, yes. I think (hope) the reason there's been so much discussion about implementation routes (= back ends) is that there's no point in specifying something that is unimplementable. And actual prototype implementations can feed back strongly into the specification. But yes, the spec is the thing. Simon

1 0

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