February 2003 - GUI - Haskell.org

Re: Gtk and Object I/O
by Axel Simon 23 Jan '06

23 Jan '06

Good day, and apologies for this very long message. On Mon, Jan 20, 2003 at 09:38:41AM -0000, Simon Peyton-Jones wrote: > I don't think we are waiting for critical user mass. We're waiting for > critical *designer/developer* mass! Yes, I guess that's what I wanted to say. So it is all about acceptance of a toolkit by the programmer. I think a GUI toolkit is more acceptable to a programmer if it fulfills the following (highest priority first): a) it is portable, i.e. programs written to use the GUI library should behave the same on Win32/X/Aqua (MacOS) b) it is functional, i.e. the programmer finds all GUI elements a modern application needs and has the ability to create custom widgets c) it is stable, i.e. the library's API doesn't change too quickly, ideally not at all d) it looks as if written with the native API of the platform I thought b) came before a), but due Simon's comment I swapped them: > Speaking as a potential user of such a library, I would absolutely love > to have a Haskell GUI library that > was available in some form on each major platform > was supported by a bunch of people, so I could have > some confidence in its continued existence > Its exact capabilities are less important: (a) I'd adapt my program to > fit what was available, and (b) I'm sure it would evolve in response to > user feedback. I'd accept compromises in functionality to gain > portability; it'd be OK to have > some platform-specific sexy bits. Worse is better. Let's assume we have a lot of time and nobody is in need of a GUI library right now. For a portable library, we need some layer which is common to all OSes. The question is thus: Where shall we have the common interface between a fixed Haskell API and the specific OS API if we want to minimize the penalty for b) functionality, c) stability and d) look-and-feel. Two main proposals are: 1) Create a common high level layer on top of all native OSes (in C) and then bind to Haskell. Example: HToolkit+Ports 2) Use the native OS functions just for drawing. Create every UI item from scratch. Example: Gtk and gtk+hs/gtk2hs regarding 1): This proposal is geared towards d), look-and-feel. It is nice to have a program which looks as if written with the native API. I think it's impossible, some flame: Dialogs in Windows are specified in dialog units, i.e. they scale with the font size but cannot be resized by the user: scrap Gtk's dynamic sizing capability. Buttons on Aqua cannot have icons in them, scrap icons in Gtk and Windows button. Scrap Aquas hierarchical view in several columns (could be simulated if Windows supports adding columns on the fly, Gtk would), scrap additional columns next to a hierarchical tree since Windows doesn't support that. Scrap Window's concept of groups in dialog and keyboard accelerators in general since Aqua doesn't know about hotkeys. AFAIK a lot of UI elements on Windows which are considered "standard" are implemented in the Microsoft Foundation Classes. Thus to actually use these, one has to use the MFC written in C++ (or .net). I know that these are all minor issues which could be circumvented, but where does the native look-and-feel go? Furthermore, this "finding the common subset" approach will certainly lead to a reduction in b) functionality. Simon PJ said: > (a) I'd adapt my program to fit what was available I wouldn't even start a *bigger* project if I would know that I hit some limits later in the development, but that's my view. > (b) I'm sure it would evolve in response to user feedback This could mean a reduction in c) stability. A major point is that you need to consider *all* platforms before you create any abstraction layer. Otherwise you will have a serious problem with stability. It would be very advisable to use a library of people who have successfully found a common subset of all OSes instead of reinventing the wheel. If we need to do it from scratch, then that could indicate that nobody has ever managed to find this common subset. Well, Sengan said: > I have seen many positive comments about IBM's SWT which > works on the following platforms: > <...everything you ever wished for...> So maybe this is such a library. Is it complete? How is the look-and-feel? -------------------------------------------------------------------------- regarding 2): Using a layer which only builds on the native drawing capabilities is surely easier to port. The b) functionality is quite good in the case of Gtk. It lacks support for sound, but supplies most UI elements known from e.g. Windows. The c) stability is not so much of a concern as the primitive drawing functions will not change that quickly. I would like to apply the "Worse is Better" principle to d) look-and-feel. In the example of Gtk, the inventors have gone through quite some hassle to make the UI changeable. You can tweak the buttons to have the same color and fonts as on Windows, though you cannot change the fact that dialogs are resizable or that buttons have no icons and flash blue if they are the default buttons (Aqua). Gtk is not ported to Aqua but runs under the XonX port of Windows. Last but not least any GUI library has to be maintained. Win32/MFC, Gtk (or Qt) and Aqua will all evolve over time. Using a single library like Gtk reduces the burden of keeping the Haskell library up to date to a single backend. Gtk has many more users as it has bindings to many other languages besides C. Thus the amount of people who can iron out problems with the ports to other platforms is much bigger. ------------------------------------------------------------------------ I did not discuss the issue of how much time it needs to implement the different concepts, that could be another email. Hope these arguments are not too biased, Axel.

9 21

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

28 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

Small JAPI binding for GHC in CVS
by Mike Thomas 19 Feb '03

19 Feb '03

Hi there. Under "fptools/libraries/Japi" (the GHC CVS repository) please find a preliminary binding to a subset of the Japi library: http://www.japi.de/ from which site you can obtain precompiled libraries and headers for different platforms. Japi is a simple C wrapper on Java which means that either "jre" or "java" needs to be in your path, but it avoids callbacks and uses the Haskell 98 FFI so I would expect it to be easy to port to "nhc98". You have to do an event loop in Haskell. The makefiles have been tested with MinGW32 GHC, but I expect you would need little effort under Linux, for example. Some examples are provided including a Fractal program, based on the C originals including the one below which will probably have mangled formatting courtesy of Outlook. Cheers Mike Thomas. --------------------------------------------------- module Main(main) where import Graphics.UI.Japi.Binding import Graphics.UI.Japi.Types import Graphics.UI.Japi.Constants import Control.Monad main = do j_setdebug 4 rv <- j_start when (0 == rv) (error "Could not start the JAPI server (jre or java)") frame <- j_frame "Frame demo" j_show (Object $ fromIntegral $ frame) icon <- j_loadimage "../c-examples/images/new.gif" when (0 == icon) (error "Could not find the icon file.") j_seticon frame icon waitForFrameAction frame return j_quit waitForFrameAction :: Frame -> IO () waitForFrameAction frame = do rv <- j_nextaction when (not (rv == (EventListener $ fromIntegral $ frame))) (waitForFrameAction frame) return ()

1 0

More points for the technical discussion
by Wolfgang Thaller 18 Feb '03

18 Feb '03

I'd just like to add a few things that should probably go into the "Technical Discussion" section: *) Dialog Button alignment and ordering Mac OS dialogs have the OK button in the lower right corner, and the Cancel button to the left of it. Most other platforms have it the other way round. Buttons in the wrong place could be very annoying to the end user, so some abstraction is needed here. *) Dialog Button naming A rather minor point: many platforms have ready-made Yes-No-Cancel dialogs. Apple expressly forbids "Yes" and "No" as button labels - they recommend using verbs ("Don't Save" - "Cancel" - "Save") instead. Might be too much work to bridge these differences, but who knows? *) File types Nowadays, MacOS applications are allowed to use extensions instead of the traditional Mac-specific metadata, so it is probably not a big issue. *) Displaying File Names and Extension Hiding Both Mac OS and Windows have an option to hide file extensions (the semantics differ in the details). Mac OS also has a feature where every file or folder on the disk can have a (possibly localized) "display name". For example, when the system language is set to German, the folder whose POSIX path is /Applications/ is displayed as "Anwendungen". It's probably too early to discuss these details yet, but I thought I'd mention them before they get overlooked. Cheers, Wolfgang

6 16

Re: Resource Files (Was: Re: [GUI] More points for the technical discussion)
by Wolfgang Thaller 17 Feb '03

17 Feb '03

On Monday, February 17, 2003, at 02:40 AM, Seth Kurtzberg wrote: > I would phrase it slightly differently. We should have a > platform-independent > API related to resources, which in some cases may use underlying > capabilities > of the target O/S. On Monday, February 17, 2003, at 11:03 AM, Axel Simon wrote: > I definitely agree to that. IMHO it is very important to use the > toolkit's > capability to custumize and internationalize the application. Every > platform has it, Windows has .rc files, Gtk has style files and Apple > has > its functionality. If we don't make use of these facilities we wind up > writing a toy (educational) API where you have 6 color constants and 3 > font constants and use them blindly. Are you sure we're talking about the same resource files here? Resources on MacOS, and, as far as I know, on Windows, have nothing to do with customization - whereas IIRC customization and "theming" are the main purpose of X11 resources and GTK style files. I was responding to Glynn Clements' statement that "User-visible text doesn't belong in the source code". For Mac OS apps, it belongs in the dialog templates (the "nib" file, a binary format editable only with Apple's Interface Builder application) and in string tables (nowadays, XML files). We don't want to end up having to draw all dialogs three times with three different (and possibly proprietary and single-platform) tools, or having to write down all user-visible text in three different file formats. On the other hand, it would be great to be able to store bitmaps and other data in the .EXE file's resources on Windows, and in the appropriate application wrapper on Mac OS, rather than cluttering the application directory with many files. As far as X-style customization is concerned, are there any features that you would expect that don't come for free? As a MacOS developer, I'd just expect some library to provide me with a way to say "store this data in the preferences/settings/defaults file" (which should be put in the standard location for preferences files). Do I have to use a particular resource format in order to be a "good citizen" on X11? Cheers, Wolfgang

5 4

Opinion summary.
by Axel Simon 16 Feb '03

16 Feb '03

Hi all, after some correcting comments, I added a summary which I would like you to have a look at. It's in the same document at: http://www.cs.ukc.ac.uk/people/staff/as49/poll.pdf Thanks, Axel.

3 10

after the opinion poll
by Axel Simon 16 Feb '03

16 Feb '03

Hi all, I summarized everything that was said on this email list. I put the result on the web and would like to ask everybody to review it and correct what I got wrong: http://www.cs.ukc.ac.uk/people/staff/as49/poll.pdf After everyone has agreed to what they've said, I'd like to formulate some sort of majority opinion and from that a mission statement. Thank you, Axel.

6 7

RE: [GUI] I love GIO.
by Simon Marlow 13 Feb '03

13 Feb '03

> > Thanks for mentioning this. However, (:=) is a rather attractive > > constructor to use > > Yes, indeed. > > > and I wonder if a monomorphic binding is used enoug to > justify taking > > another operator away. > > The choice between polymorphism and sharing is fundamental > enough that I > think it's worth an operator symbol (*). Of course it > doesn't need to be > (:=), but it shouldn't be too weird, either. BTW, you can specify a monomorphic binding in GHC by using a result type signature. eg. x :: a = ... is a monomorphic binding for x. The type variable 'a' need not be in scope, although this binding brings it into scope in the body of x. This behaviour is the result of some recent changes to the scoped type variable extension, IIRC. The documentation looks like it could do with some updating. Cheers, Simon

1 0

RE: [GUI] after the opinion poll
by Simon Peyton-Jones 12 Feb '03

12 Feb '03

Well done! Elements of the consensus (your section 2) seem to be * Cross-platform portability is very important, meaning: the same Haskell program should run on many platforms * The primary goal is to define a mid-level API, at the general level of Object I/O or GIO * The implementation technology (i.e. which underlying library is used) is not part of the specification. Indeed, it's a goal that the specification should constrain the implementation technology as little as possible. Specifically: (a) the specification should be such that it is possible to implement the spec with native look and feel (b) the specification should be such that a free-software implementation is possible I'd like to suggest a non-goal * The specification API should be Haskell 98 GUIs are an area where muti-parameter type classes and existentials are really useful, and it's a pity not to use them. Let's stick to features in the intersection of GHC and Hugs, though. Simon | -----Original Message----- | From: Axel Simon [mailto:A.Simon@ukc.ac.uk] | Sent: 11 February 2003 23:52 | To: gui(a)haskell.org | Subject: [GUI] after the opinion poll | | Hi all, | | I summarized everything that was said on this email list. I put the result | on the web and would like to ask everybody to review it and correct what I | got wrong: | | http://www.cs.ukc.ac.uk/people/staff/as49/poll.pdf | | After everyone has agreed to what they've said, I'd like to formulate some | sort of majority opinion and from that a mission statement. | | Thank you, | Axel. | | _______________________________________________ | GUI mailing list | GUI(a)haskell.org | http://www.haskell.org/mailman/listinfo/gui

3 2

wxWindows and MacOS
by Krasimir Angelov 12 Feb '03

12 Feb '03

Hi, all Is there anybody which is tried wxWindows under MacOS? How native is it under Mac? Krasimir __________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com

2 1

haskell-gui: Second edition.
by David Sankel 03 Feb '03

03 Feb '03

Hello Everyone, I was doing a contract in New Mexico for a few days. I was certainly surprised to find ~100 messages in my inbox concerning GUIs in haskell. Aside from the several digressions and repititions in the archive (I think if I hear "why not just use gtk?" one more time, I'll pull out my teeth), there was a wealth of extremely valuable information. It also shows that there is a lot of (heated) interest. So, I'm officially going to get this project going. I'm going to try to address the concerns that I though stood out: 1. Why do I suggest using QT as a basis? I was suggesting using QT's feature set as a basis and probably their methodology for multiplatforming. The programmer-interface of QT, whether you want to call it low, mid, or high-level works really well. I've designed and implemented a piece of cross-platform CAD/CAM software (a great example where UI is of extreme importance) using QT. QT worked wonderfully for this project. No other GUI toolkit out there (in any language) could have succeeded with our given time constraints. QT has been a success in this project and countless others. The look and feel for all platforms deployed far succeeded our requirements. 2. Why not use QT itself? I assume this means using QT as a thin wrapper. a) QT is too high level of a library to just move to another language. Haskell certainly needs it's own low-level library. b) QT isn't even written in standard c++. I hate pre-compiler steps (moc). c) QT is proprietary. This is unacceptable for a standard haskell gui library. 3. Why not incorporate XML into the gui for a document model? This is, of course, nice for certain gui situations. However, this is something that could be done after the mid-level libraries are complete. So, for now, I'll put this question on the shelf. 4. Which system should be used for a reference implementation? (windows or linux) I don't really care. Those who plan on contributing, please tell me what OS you would prefer to use. 5. Is haskell ready for High level GUI? No. Fudgets and friends are nice, but they are out of the scope of this proposal. Until something really cool comes up, we can basically forget about high level functional libraries in our context. 6. Htoolkit/port/ObjectIO? These are the places to start this project. ObjectIO is not sufficient as is. I'm leaning towards the low-level/mid-level interfaces with an ObjectIO type mid-level. What do people think about the port library as it is right now? http://www.cs.uu.nl/~daan/doc/port/Graphics.UI.Port.html What needs to be changed? How can it be improved? Is it flexible enough? 7. Concurrency? What do you all think about this? Is there anything we can do specifically to integrate it into a GUI library? 8. What about using other high level libraries? For this project, I believe it to be easiest and best to not use other high level c or c++ libraries as a basis. I agree mostly with Adrian's comments regarding this. Axil's comments were mostly discussing applications and current work on this idea. 9. What about the Mac? Macs are not a priority. A Mac backend would be nice but whether or not it adheres to the mac recommendations on style are not important. If someone really wanted to write an application that looks absolutely native on all three platforms, they should write using: gtk+hs mac+hs w32+hs and not with haskell-gui. I do not wish to get rid of the other existing libraries. On contrary, I hope they continue progressing. I wish for a standardized gui framework for haskell. David J. Sankel Head Consultant Electron Consulting (www.electronconsulting.com)

2 1

ByeDemo
by Arjan van IJzendoorn 01 Feb '03

01 Feb '03

Hi, Here's a Java version of the Bye demo (John Meacham). I think any Haskell library should at least look better than this. Arjan

1 0