- GUI - Haskell.org

Re: GUIs and events/callbacks
by George Russell 10 Mar '03

10 Mar '03

Glynn wrote (snipped) > Does this mechanism allow the toolkit to determine whether an event is > being listened for? Or would it force the toolkit to always generate > all events just in case it's being listened for? The latter is > unacceptable on X. Yes. You'll see I provided an IO *action* clicked :: Clickable widget => widget -> IO (Event ()) This tells the toolkit to *generate* an event whenever a button (or whatever "widget" is) is clicked. I agree that the alternative, for general GUI events, would be unacceptable.

2 1

wxwindows and native look and feel
by Nick Name 07 Mar '03

07 Mar '03

I don't know if this is true, but my professor of "Graphical interfaces" told me some month ago that wxwindows is not really "native look and feel" on windows, since for example the "file open" dialog is not native. At the same time, wxwindows has its own format for resources, and the "file open" dialog is not native under gnome (even if it's better than the gnome one). Anyone wishing to clarify? Vincenzo PS: Maybe the wxwindows experience should tell us that what we are looking for is impossible to reach?

2 2

How to create objects and how to get/set their attributes
by David Sankel 07 Mar '03

07 Mar '03

Thanks to Wolfgang for sorting out the current discussion topics. I hope this to be the thread for 1 on the issue list. There have been three, that I have seen, competing ideas. The first is the GIO/Object IO style of objects: button <- Button [ title =: "Hello", position =: (0,0), size =: (300,50) ] set button [ onPress =: (buttonPressed button) ] set parentWindow [children ~= (/a -> button:a)] The second is a motif style (please correct me if I have this wrong): button <- create "Button" parentWindow [ title =: "Hello", position =: (0,0), size =: (300,50) ] set button [ onPress =: (buttonPressed button) ] The third is the OO approach button <- new Button button # setOnPress (buttonPressed button) button # setPosition (0,0) button # setSize (300,50) parentWindow # addChild button I propose we use the GIO/Object IO style. Does anyone have any other preferred styles that I'm missing? Which style do you prefer? David J. Sankel

4 4

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