January 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

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

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

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