- GUI - Haskell.org

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 18 Feb '03

18 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 17 Feb '03

17 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 17 Feb '03

17 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 13 Feb '03

13 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