January 2003 - GUI - Haskell.org

crass platform? Htk?
by George Russell 24 Jan '03

24 Jan '03

Shae Matijs Erisson wrote [snip] > I've just tried the latest version announced yesterday on the primary haskell > list. It works on my Debian Linux box. > I haven't tried it on windows, I don't have one available. > I don't know if Tcl/Tk works on Mac at all. (but would like to know) [snip] As one of the authors, I am very grateful for the endorsement. Always nice to receive assistance in our quest for world domination ... I have tested HTk (and it works) on Windows (both 98 and NT), Linux and Solaris. Or at least I hope it does; if it doesn't please complain to me ... I believe it would work on Mac OS X, because that does indeed have Tcl/Tk (almost every system does) and GHC. The compilation needs a Unixy environment, but no more than say MinGW or Cygwin provide on Windows (I have compiled with both). [snip] > Admittedly, Tcl/Tk is ugly enough to be called "crass platform" but it would > follow the "Worse Is Better" approach. [snip] You can improve the look of Tcl/Tk somewhat, and add other widgets, by using "tixwish" instead of "wish". http://tix.sourceforge.net/ If you build HTk with tixwish in your path, it will default to using that instead of wish. Or you can switch between the two by setting an environment variable before running your programs. Alas though there is a bug in tixwish (reported but as yet not fixed) which means it won't work on Windows, so there you do have to use wish. Only problem is I don't at the moment have access to a Mac (or FreeBSD). If someone would like to build binaries for me, I'd be very grateful to help. However the following *allegedly* works, where $TAR is GNU tar, and $MAKE is GNU make. Make sure that ghc, wish, and the GNU linker gld or ld are in your PATH. The build process needs other programs, but looking at ./configure's output should tell you if there's a problem, and if so what. wget http://www.informatik.uni-bremen.de/htk/download/uni-0-99-src.tar.gz $TAR -xvzf uni-0-99-src.tar.gz cd uni ./configure $MAKE packages $MAKE prepareexports $MAKE exports Hope this helps, George Russell

2 1

crass platform? Htk?
by Shae Matijs Erisson 24 Jan '03

24 Jan '03

What about Htk? I've just tried the latest version announced yesterday on the primary haskell list. It works on my Debian Linux box. I haven't tried it on windows, I don't have one available. I don't know if Tcl/Tk works on Mac at all. (but would like to know) Admittedly, Tcl/Tk is ugly enough to be called "crass platform" but it would follow the "Worse Is Better" approach. Maybe it would be faster to build the platform independent interface on top of the already working Htk, and add Gtk/Qt/etc support later? Htk - http://www.informatik.uni-bremen.de/htk/ has linux, solaris, and windows binary builds on the downoad page. -- Shae Matijs Erisson - 2 days older than RFC0226 #haskell on irc.freenode.net - We Put the Funk in Funktion

2 1

Portable GUI libraries
by Simon Marlow 24 Jan '03

24 Jan '03

Just thought I'd weigh in with MHO. It seems to me that it comes down to picking two of the following: 1. Portable GUI library 2. Rich widget set 3. Native look and feel Sometimes you can make a pretty good stab at the third, but it's not possible to do a good job on all three simultaneously. It's just a question of what you want to compromise. We have examples of each combination: 1 & 2: Gtk, Qt, wxWindows, Tcl/Tk 1 & 3: ObjectIO, ? 2 & 3: MFC, Gtk & Qt (On X11 only) Personally I'd use the 2&3 libraries, and rewrite my GUI for each platform. For building quick portable prototypes, I'd appreciate a library that falls into the 1&3 category too, but I won't expect it to be as full-featured or native-looking as a 2&3 library. Cheers, Simon

2 1

Fruit Source
by Thomas L. Bevan 24 Jan '03

24 Jan '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Does anyone know if the FRUIT source code is freely available somewhere? Tom -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+MKwNGse0w80KF2gRAh7NAKCyBzaljB+cRJZDC+z4ckhZ8zOjZACgsNPk ivDRYrmLaDfjQZDFK+0yY4w= =AS7R -----END PGP SIGNATURE-----

3 3

RE: [GUI] Proposal Proposal: haskell-gui addendum to haskell
by Simon Peyton-Jones 23 Jan '03

23 Jan '03

| Perhaps the best would be to use an Object-IO like interface | with mvars as proposed by Simon Peyton-Jones, simply because it's | higher level than raw gui-calls and the Clean folks have used | it cross-platform in a few real apps. Indeed. My impression is that we won't get far trying to design a truly high-level declarative GUI toolkit, because there just isn't enough consensus on what it should look like. There have been a number of very interesting experiments, but none has captured everyone's attention. I just don't think we yet know the answer here, though I am hopeful that further exploration will eventually uncover it (or them). Meanwhile, lacking the Final Answer, we need a practical solution. One possibility would be to adopt some multi-platform toolkit like Gtk, and provide a Haskell wrapper for each function. Several such bindings exist. But that is (a) terribly low level, (b) very toolkit-specific. I think we can do a bit better. My personal favourite is the Clean Object-IO story: it's higher level and more abstract than just a simple imperative veneer over (eg) Gtk, but it's still low level enough that its not hard to implement. Furthermore, the Clean folk have a developed over a decade, so they have *lots* of experience of using it in real applications. Let's take advantage of their wisdom; I would be surprised if we could do better if we started from a blank sheet of paper. So I propose the Clean Object-IO approach as a reasonable compromise starting point for the programming interface. (I'm entirely agnostic about what is the most suitable underlying C library to use; indeed, the choice of that library should ideally be un-discoverable to the programmer.) I say "starting point" because there are still plenty of design choices to be made. For example, to use the Clean "local state" idea or use MVars? This choice is discussed in the paper that Peter Aachten and I wrote: http://research.microsoft.com/~simonpj/Papers/haskellobjectio.htm I'm sure there are many other choices. This suggestion is not based on deep study. Maybe others have better ideas. But I counsel against trying to find a truly high-level design. Worse is better. Simon

2 1

Proposal Proposal: haskell-gui addendum to haskell standard
by David Sankel 23 Jan '03

23 Jan '03

Hello Everyone, I believe that haskell would have great benifit from a platform independant specification for a graphical user interface module or set of modules. I've been blessed with a lot of time on my hands so I'd be willing to organize this project if needed. Since there are several working haskell gui libraries out there, I would like this to be a collaboration project with those who are experienced in this area. Input and ideas from users would also be a part of the collaberation. The goal would be a specification much like the haskell report that could be freely implimented and a reference impementation. This is an informal proposal for a proposal and would like to get some feedback for the following ideas. (please reply to gui(a)haskell.org) 1. Platform independance: The QT widget library is a stunning example of how platform independance is achievable without sacraficing speed. I am not suggesting that we build haskell-gui off of QT but might use major components of it as a model. Eventually, the library could have three backends; the Windows API, the X API (or gtk perhaps?), and the Mac API (the name illudes me at the moment). 2. Signals support: Having a signals mechanism is essential for large gui projects. 3. Dynamic widgets: All widgets should have dynamic size and should have the ability to be resized by the measurement of their contents or their parents. This could be done in a way similar to QT widgets. 4. GUI GUI builder: Widgets should be flexible enough to have the ability to be incorporated in a GUI GUI builder program, such as QT designer. The storage for a GUI builder might be direct Haskell code or some intermediate format. 5. OpenGL incorporation: haskell-gui should have some sort of OpenGL widget as OpenGL is the most standardized and multiplatform graphical library availible. Perhaps the hgl software could be incorporated in this aspect of haskell-gui. 6. Custom Widgets: It should be easy for one to create his or her own custom widgets from scratch using Haskell code or by some modification of the standard ones. Please give your feedback and suggestions for this project proposal proposal. If there is enough interest, I'll get this thing started. Kudos, David J. Sankel Head Consultant Electron Consulting (www.electronconsulting.com)

8 9

RE: Gtk and Object I/O
by Krasimir Angelov 20 Jan '03

20 Jan '03

--- Simon Peyton-Jones <simonpj(a)microsoft.com> wrote: > | going to stop gtk+hs because of this". So it seems > we are all > | waiting for the critical user mass that makes our > own beloved > | GUI library (binding) the standard GUI library. > For the sake > | of Haskell, we can only hope that this will > actually happen > | one day. A sad side-effects of this is that most > of us GUI > | developers waste a tremendous amount of time. A > paper is just > | not worth the effort we put in writing the code. > > I don't think we are waiting for critical user mass. > We're waiting for > critical > *designer/developer* mass! > > Before Haskell existed, there were half a dozen > not-very-good lazy > functional languages, roughly one for each research > group. Haskell was > born out of the realisation that our efforts were > fragmented and > duplicated by this language diversity. Perhaps the > situation with GUIs > today is similar. > > What is necessary is for those who are enthusiastic > about developing GUI > technology to get together and hammer out a common > design; and then > co-ooperate in implementing and supporting it. The > hard bit is for > everyone to compromise enough to agree a common > design. For that to be > feasible you either need a fair consensus on the > broad outlines, or > enough frustration with the costs of diversity that > everyone is prepared > to make substantial compromises. I sense that the > latter condition may > hold. I'm not sure about whether there's a > consensus on what a GUI > library should look like to the programmer, but at > least the current > diversity means that there are quite a few > more-or-less worked-out > designs to serve as concrete starting points. > > 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. > > > As Manuel says, this process is already under way: > the GUI task force. > > http://haskell.org/communities/11-2001/html/report.html#sect4.3.1 > But not much is happening on gui(a)haskell.org. > Well, nothing actually. > Most of the 63 people subscribed to the list are > (like me) lurkers. > But I bet that a small subset are knowledgeable > enough and motivated > enough to do the job. > > My main purpose, in writing this over-long message, > is to say again what > a big service to the community it would be to agree > a common design and > to implement it. > > > Simon I am completely agree. The development of the ObjectIO and HToolkit was very interesting to me because this allows me to compare GTK and Win32. I understand that independently of the external differences of these API-s they have mostly similar features. The main differences I found are: * The GTK cannot draw rotated text and rotated elipses. This depend on restrictions imposed from X server. * The Win32 backed lack powerful text formating features like these given from PANGO. * The Font families given in the GTK and Win32 are rather different. The font management are still similar on each platform. Probably there are also other differences but I hope that they are not so important. I don`t have any expirience with Mac platform and don't know how different is it. I expect to hear other opinions in gui(a)haskell.org mailing list. Krasimir __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

1 0