February 2003 - GUI - Haskell.org

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

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

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

18 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