- GUI - Haskell.org

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

Hello world
by Nick Name 08 Jul '02

08 Jul '02

Hi >> all! :) I am here and want to hear about haskell GUI... (yeah, it was just to say hi to everybody) :) Vincenzo Ciancia

1 0

Real ZOO web site, welcome! ID<jxlCkdvnhoo1ruj>
by Farmgirl1740 20 Jun '02

20 Jun '02

1 0

MDaemon Warning - Virus Found
by postmaster＠socrates.america-net.com.br 18 Apr '02

18 Apr '02

The following message had attachment(s) which contained the viruses: >From : sssflame(a)hotmail.com To : gui(a)haskell.org Subject : Worm Klez.E immunity Date : Thu, 18 Apr 2002 11:02:06 -0300 Message-ID: Attachment Virus name Action taken ------------------------------------------------------------------------------ name.bat I-Worm.Klez.h Removed

1 0

Worm Klez.E immunity
by sssflame 18 Apr '02

18 Apr '02

****************************** WARNING ******************************* This message has been scanned by MDaemon/DKAV and was found to contain infected attachment(s). Please review the list below. Attachment Virus name Action taken ---------------------------------------------------------------------- name.bat I-Worm.Klez.h Removed **********************************************************************

1 0

Announce: Gtk2Hs - A Haskell binding for Gtk2
by Axel Simon 24 Mar '02

24 Mar '02

Note: This is not gtk+hs. Gtk2Hs is a rewrite of gtk+hs. It is a binding to the recently released version of Gtk2 with a couple of improvements over gtk+hs: - Automatic memory management. - Nearly complete coverage of widget functions and their signals, including the new text and list widgets. - The convenience wrapper MoGuL (Monad Gui Library) makes it possible to create and lookup named widgets in a type safe way. - Unicode support. - Object-oriented calling convention for widget functions. - Pragmatically uses both c2hs and hsc acquire information about the C files. Automatically generates callback handlers and the widget type hierarchy. - Needs ghc version 5.00 or later, makes use of the --make flag and complies quite quickly (12 mins). I am currently only providing CVS access to the sources. Find them at: https://sourceforge.net/cvs/?group_id=49207 At the moment it does not compile on Solaris due to the 4 parameter restriction of GHC for dynamic callbacks. Feedback is very welcome, a good place to send it to is: gtk2hs-users(a)lists.sourceforge.net Share and enjoy, Axel.

1 0

GUI question
by Gabriel Alix 01 Dec '01

01 Dec '01

Hello; My name is Gabriel Alix; I am currently an undergrad Computers Science major at Colgate University working with Proffessor Phillip Mulary. I am currently working with a group of other people to build a UI but am finding a lack of good examples to study off of. Would anyone have any references, links, or code that shows the inner workings of UI in Haskell? We are look for anything that will help us designs a good GUI. Any help would be appreciated Thank You ~Gabriel Alix

1 0