- GUI - Haskell.org

Fw: Terminology (Re: [GUI] Re: Know you backends)
by Daan Leijen 31 Jan '03

31 Jan '03

> I propose a simple program which pops up a window saying > 'Hello World' with a button saying 'Bye' which you click and it changes > the message to 'Goodbye'. if you click the button again the program > exits. Hi all, Here is the GoodBye demo for the Port library. (a portable core-functionality library). I think that it nicely shows the difference between a library with a nice convenience layer, like GIO, and a bare gui library like Port. It also shows that Port is still at a reasonably high-level from a gui perspective: writing this example with just the Win32 library for example is much more work. All the best, Daan. -------------------------------------------------------------------------------- {--------------------------------------------------------------------------------This program implements the "goodbye" demo as posted by John Meacham onthe Haskell GUI mailing list. --------------------------------------------------------------------------------}module Main whereimport Graphics.UI.Portmain = do demo -- setup gui start -- start event loop demo :: IO ()demo = do w <- createWindow registerWindow w -- register for proper shutdown when the window is closed registerWindowDismiss w (closeWindow w) -- close when the user dismisses the window registerWindowPaint w (\can upd -> fillRect upd can) -- fill the background with some color setWindowDomainSize w (Size 0 0) -- no scroll bars needed setWindowViewSize w (Size 80 40) -- guess some size as Port has no layout manager setWindowTitle w "Bye!" -- set the title bar text l <- createLabel w setLabelText l "Hello World!" lsize <- getLabelRequestSize l -- get the minimal size of the label moveResizeControl l (rectAt (Point 0 0) lsize) -- position in upperleft corner b <- createButton w setButtonText b "Bye" bsize <- getButtonRequestSize b -- get the minimal size of the button moveResizeControl b (rectAt (Point 0 (sh lsize)) bsize) -- position under the label registerButtonClick b (bye w l b) -- register event handler showWindow w -- show it all where -- called on the first click with the window, label, and button as arguments. bye w l b = do setLabelText l "Goodbye" registerButtonClick b (closeWindow w) -- overwrite the old event handler

1 0

Re: [GUI] Compiling HToolkit.
by Axel Simon 29 Jan '03

29 Jan '03

On Mon, Jan 27, 2003 at 04:57:39AM -0800, Krasimir Angelov wrote: > Try to do > $ make depend > $ make > $ make install > The OS directory exists in CVS. Yes, it does, sorry. But how is ghc supposed to find it? I get: ~/source/HToolkit:$ gmake depend /home/as49/local/bin/ghc -M Graphics/UI/HGUI/OS/Window.hs Graphics/Rendering/HGL/Font.hs Graphics/UI/HGUI.hs Graphics/UI/HGUI/BasicClasses.hs Graphics/UI/HGUI/BasicTypes.hs Graphics/UI/HGUI/Button.hs Graphics/UI/HGUI/CheckBox.hs Graphics/UI/HGUI/Edit.hs Graphics/UI/HGUI/Event.hs Graphics/UI/HGUI/EventTypes.hs Graphics/UI/HGUI/FileSelectors.hs Graphics/UI/HGUI/Form.hs Graphics/UI/HGUI/GraphViz.hs Graphics/UI/HGUI/ListBox.hs Graphics/UI/HGUI/Menu.hs Graphics/UI/HGUI/PopUp.hs Graphics/UI/HGUI/RadioBox.hs Graphics/UI/HGUI/Text.hs Graphics/UI/HGUI/OS/Types.hs Graphics/UI/HGUI/OS/Util.hs Graphics/Rendering/HGL.hs Graphics/Rendering/HGL/BasicClasses.hs Graphics/Rendering/HGL/BasicTypes.hs Graphics/Rendering/HGL/Bitmap.hs Graphics/Rendering/HGL/DrawMonad.hs Graphics/Rendering/HGL/Drawing.hs Graphics/Data/Geometry.hs Graphics/Rendering/HGL/BasicTypes.hs: can't locate import `Graphics.Rendering.HGL.Bitmap' (SOURCE import) gmake: *** [depend] Error 1 Axel.

1 0

Proposal for MacOS MenuBar
by Krasimir Angelov 28 Jan '03

28 Jan '03

I propose simple scheme for portable for menus based on two simple ideas: 1. We can define two separatate menu types. - Common menu bar: this is a menu with commands which are common for each toplevel window. Usually native Windows applications has three common sub-menus in the menu bar: the first menu is usualy File, the second is Edit and the last is Help. If the application supports View menu usually this is the third menu. - Document menu bar: each toplevel window can have its own menu with its own commands. Under Windows MFC based MDI applications supports different menus for each document types but usually for all of them exists the same File, Edit, View and Help menus. I think that is good idea to express this fact more natural. The Haskell GUI library can define one common menu and the place, where the document menus to be placed. When any window becomes active its menu will be merged with common menu. When there aren't active windows then the MDI frame will display just default menu. I hope that this can be suitable for MacOS. This convention will encourage developers to define the common menu and the document specific menus and then leave OS specific layer to build application menu in natural way. 2. We can explicitly define the document model which are most suitable for the application (MDI, SDI or NDI). The model must be specified at startup just like in the ObjectIO. The meanings of models are: - SDI - Under Windows and GTK we have multiple top level windows and usually the application finishes when all windows are closed. Each window has its own menu which are part of the window. Under acOS the difference is that the application continues execution even if all top level windows are closed. The menu is placed at desktop. - MDI - Under Windows we have one toplevel MDIFrame with many child frames and the application finishes when its MDIFrame is closed. Under GTK we have one toplevel window with embeded GtkNoteBook widget. The child frames are expressed with pages in the notebook and the application finishes when the toplevel window is closed. Under both Windows and GTK, the menu is placed on MDI frame and it is a composition of the common menu and the current document menu. Under MacOS MDI interface will have the same behavior as SDI. - NDI - simple interface with just one dialog without MenuBar. Krasimir __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

2 1

Re: [GUI] MacOS Menu Bars (was: Re: Portable GUI levels)
by Wolfgang Thaller 27 Jan '03

27 Jan '03

(sorry, forgot to send to the list at first, that reply button was so inviting...) seth(a)cql.com wrote: > I would say one menu bar per autonomous window, not one per > application. What's an "autonomous window"? Never heard that term... (let's see if it can be applied to all platforms...) Cheers, Wolfgang Thaller

1 0

Compiling HToolkit.
by Axel Simon 27 Jan '03

27 Jan '03

Krasimir, Daan, I get: /home/as49/local/bin/ghc Graphics/UI/HGUI/OS/Window.hs -O -c -fglasgow-exts -Iincludes -I/usr/local/include -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/atk-1.0 -I/usr/X11R6/include/pango-1.0 -I/usr/X11R6/include/gtk-2.0 -I/usr/X11R6/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/local/include/freetype2 -I/usr/local/include -package-name HToolkit Window.hsc:24: failed to load interface for `Graphics.Data.Geometry': Could not find interface file for `Graphics.Data.Geometry' Window.hsc:25: failed to load interface for `Graphics.Rendering.HGL.BasicTypes': Could not find interface file for `Graphics.Rendering.HGL.BasicTypes' Window.hsc:26: failed to load interface for `Graphics.UI.HGUI.BasicTypes': Could not find interface file for `Graphics.UI.HGUI.BasicTypes' Window.hsc:27: failed to load interface for `Graphics.UI.HGUI.OS.Types': Could not find interface file for `Graphics.UI.HGUI.OS.Types' Window.hsc:28: failed to load interface for `Graphics.UI.HGUI.OS.Util': Could not find interface file for `Graphics.UI.HGUI.OS.Util' gmake: *** [Graphics/UI/HGUI/OS/Window.o] Error 1 There is no directory OS in HGUI. I configured with ./configure --with-hc=/home/as49/local/bin/ghc --enable-gui Axel.

1 0

RE: [GUI] Re: Gtk and Object I/O
by Simon Peyton-Jones 26 Jan '03

26 Jan '03

The discussion has focused so far somewhat on implementation routes. My hope is that (A) we can define programming interface (i.e. a collection of abstract types and functions) (B) that is rich enough to be useful for writing GUI applications (C) and yet can be mapped onto a variety of architectures and toolkits If this were possible, then one could reduce effort in step (C) by using a toolkit (e.g. Gtk) that is already ported to multiple architectures, at the cost of look-and-feel; or, one could maintain look-and-feel compatibility by investing more in (C), so that the mapping was more native-aware. Regardless of which approach an implementor took, the application writer would still use interface (A). The question is: what should (A) look like? Is it even possible to define a rich enough (A) without making (C) impossible? The answer to the latter question must surely be "yes, provided one is not too ambitious with (A)". 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 That would be even better, because then lots of the implementation of (A) becomes shared between many targets. The Clean experience is that the code sharing is substantial. So I ask: what are the candidates for (A)? I've suggested one: the Clean Object-IO model, or something related (the MVar vs local state question is still open). Are there any other proposals? Simon

9 14

Re: [GUI] Proposal Proposal: haskell-gui addendum to haskell standard
by Peter Achten 24 Jan '03

24 Jan '03

Dear all, I would like to elaborate on a number of things that have been said recently about Object I/O (be it in Clean or Haskell). Object I/O has been designed to be platform independent: it is separated into two layers: one OS dependent layer and one abstract Clean/Haskell layer built on the lower layer. The OS dependent layer has been implemented for the MS Windows platform and we are currently working on a Mac port. Krasimir Angelov has tried to port it to GTK, and says that the OS dependent layer apparantly still has an OS bias that makes it less suitable for GTK. He mentions the following differences: [Krasimir Angelov at: 02:21 20-1-03 -0800] > * 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. * Graphics features will always differ on all platforms. Object I/O anticipates on this by offering an open-ended graphics API. Type classes for drawing and filling (Drawables and Fillables respectively) are defined as well as a limited set of standard instances (lines, curves, rectangles, text). To extend the graphics capabilities one can simply create a new module in which these new instances are declared and implemented. This has for instance been done to extend the graphics library with the ability to render bitmaps. * I don't see why one would need these text formatting features in this context. Perhaps Krasimir can explain this? * Font family naming conventions already depend on the particular set of installed fonts on a machine. A decent program can therefore never assume the existence of whatever font, and it should try to find out this information via the OS. I would certainly not be surprised if the OS dependent layer of Object I/O indeed has an OS bias, but the above points don't seem to be problematic to me. Please note that I have no experience with Gtk. However, for an old version of Object I/O we have had a Master Thesis project porting it successfully to X Windows (using the OpenLook toolkit). My guess is that Gtk is inspired by the X Windows approach. Again, Krasimir can elaborate on this. One big advantage of a two-layered approach is that applications can have a native look-and-feel. Although I am perfectly aware of the burden of keeping ports up-to-date, I think it is very important that applications written in the "standard" GUI library for Clean/Haskell behave as others. People (even scientists) do get annoyed when confronted with applications that do not conform to the normal behaviour. The two-layered approach also does not exclude a port to a platform indepent toolkit, so that might serve as a starting point. Finally, a well-documented and well-defined OS dependent layer will ease the development of high-level GUI libraries. Researchers will not need to re-invent the wheel and see the result of their implementation effort more quickly. [Axel Simon at: 14:45 23-1-03 +0000] >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). This has partially been answered by Krasimir. In addition, I would say that the answer to these differences is abstraction. As an example, consider resizing of controls. In Object I/O, a control can have a resize attribute that defines its size in terms of the size of (one of) its parent(s). When put in a resizeable parent object that is resized, it will resize according to its attribute. If the platform does not allow resizeable dialogs/windows, then that is no problem. Similar to icons in buttons: add an attribute to specify the icon in a button and if the platform does not support it, you don't show it. No scrapping needed; good set of attributes and semantics needed. [Sengan.Baring-Gould at: 13:21 22-1-03 -0700] >While programming at the IO level works, it does not give one >much of an advantage versus programming in C, in sharp contrast >to most other Haskell programming. > >The diversity of high level solutions which differ totally in >outlook ("express the widget as a datastructure" versus >"everything is a composition of functions") gives the impression >that the library designers never used their toolkits in larger >applications which would have made any rough edges painfully obvious. >It seems therefore that a lot more work needs to go into this field >before we know what a good high level Functional GUI toolkit looks like. >Contrast this with more mature fields such as pretty printing, >parsing, etc where there are many solutions all following the same >ideas. I don't agree with the "does not give one much of an advantage versus programming in C". Many proposals have been written that make use of the elaborate type system of functional languages to glue correct GUI programs; many approaches use functional language features do construct well-typed and well-structured Domain Specific Languages. "...the library designers never used their toolkits in larger applications..." True: I didn't, but other people have. Check out the CleanIDE (by Diederik van Arkel): http://www.cs.kun.nl/~clean/About_Clean/body_the_clean_ide/body_the_clean_i… and the beautiful Sparkle Proof Tool (by Maarten de Mol): http://www.cs.kun.nl/~maartenm/Sparkle/ Regards, Peter

4 3

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