- GUI - Haskell.org

GUI meeting at ICFP?
by Daan Leijen 24 Jul '03

24 Jul '03

Dear all, As you may know, the ICFP conference and Haskell workshop are held at the end of August in Uppsala, Sweden. I don't know how many of you will attend, but maybe we can organise a (small) meeting of people interested in GUI's over there and talk about the future of GUI's in Haskell. Maybe even as part of the Haskell workshop? I think it would be very good to talk with people in person, and maybe there is even room for giving demos or short presentations -- depending on time, space, and the number of people able to attend. I am going on a holiday for the next three weeks so I am not able to reply on this message, but maybe if enough people are interested we could discuss a time and place later on. (maybe Axel can keep track of who could attend or not?) Well, I hope something can be arranged, and if so, I will certainly be there :-) All the best, and good holidays, Daan.

3 2

HToolkit 1.0 released
by Krasimir Angelov 24 Jul '03

24 Jul '03

+-------------------------------------------------------+ | ANNOUNCEMENT: HToolkit 1.0 released | +-------------------------------------------------------+ | author: Krasimir Angelov | | www : http://htoolkit.sourceforge.net | | forum : mailto://htoolkit-users@lists.sourceforge.net | +-------------------------------------------------------+ The HToolkit is a package primary intended for development and designing of platform independent graphical user interface. The package gives you an abstract API for many platforms while for each platform are used only libraries which are native for the platform. This release supports only Windows and Linux platforms, but the chosen model allows support for other platforms. Under Windows the package use only native Win32 API and under Linux are used GTK/GNOME libraries. The difference between HToolkit and most of other libraries is that the latter uses only controls and dialog elements which are native under target plaform. The advantage of this is that the application looks like more native. Similar model is chosen from wxWindows for C++ and SWT for Java. The disadvantage of this libraries is that they are written in high level languages and this makes difficult to use them from other languages. The main part of HToolkit is written in C and the used model simplifies FFI interface between the HToolkit core and high level languages (most languages proposes only FFI to C). The current release gives only interface to Haskell. There is plan to build GUI libraries based on HToolkit core for C#, SmallTalk and Python. HToolkit for Haskell -------------------- HToolkit �� Haskell is divided in two libraries: GIO and Port. The Port library is a low level interface and it is not intended to be used for development. Port includes modules written in C and FFI for them written in Haskell. GIO is a high level API intended for application development. The HToolkit is divided in high and low level in order to allow development of experimental high level interfaces without sacrifice of low level API. For the time beings HToolkit gives all features proposed from ObjectIO with exception of ToolBar and CustomControl. Many of ObjectIO features are extened, but there are also many new features which does't exists in ObjectIO. Relatively all controls supported from wxHaskell are supported from HToolkit. Still missing controls like Panel, Gauge and Notebook but they are planned for the next release of HToolkit. Currently the HToolkit is the only package for Haskell which allows to create, load, edit and save images at runtime. Another interesting feature is that the toolkit allows to display icons in menu items. The feature is native under GTK/GNOME but is hard to implement under Windows. NOTE: The ToolBar support is included in the package but still doesn't work. This is because under Windows it still requires a bit of development while under GTK/GNOME the package uses the new API for GtkToolbar which will be part of the next GTK release. Krasimir Angelov __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

3 7

RE: [GUI] GUI meeting at ICFP?
by Simon Peyton-Jones 24 Jul '03

24 Jul '03

| > I'm not against sexy, interesting designs built by one person -- far from it | > -- but I desperately want One Thing that is multiply supported, even if the | > One Thing is not very sexy. | | Well, people probably won't use the interesting alternative libraries because | they have a standard platform. The problem I see is that we get a not so well | designed standard interface and better approaches just don't have a chance to | get widely used. The problem I'm addressing is that if there is no standard GUI platform for Haskell, people won't use Haskell at all (let alone the interesting GUI alternatives!). Surely "better approaches" have had every chance to be widely used! We've tried the "let a thousand flowers bloom" approach for about ten years, hoping that one or more GUI libraries will emerge as widely-accepted alternative, and it just hasn't happened. That's why I advocate the boring "agree a non-sexy standard platform" approach. I should have said in my earlier message that I am, of course, only expressing my own view, partly in the hope of stimulating debate. Perhaps one reason for lack of convergence is lack of agreement about the main goal. If so, we should clear that up before getting into detailed design. Simon PS: A standard interface does not necessarily have to be "not so well designed". It can be well designed, but perhaps not as rich as the more interesting alternatives.

1 0

Packaging, and GUIs
by Simon Peyton-Jones 23 Jul '03

23 Jul '03

Dear Haskell library and GUI folk, Here's an interesting message from the Caml mailing list, largely focusing on a) packaging b) GUIs Interestingly, the very two topics on which we have active groups working! I wonder if it'd be a good time for a status report from both efforts? Both have been very quiet of late, but I see that Daan and Krasimir have both published new GUI libraries recently, so GUI stuff is still going on. Simon -----Original Message----- From: owner-caml-list(a)pauillac.inria.fr [mailto:owner-caml-list@pauillac.inria.fr] On Behalf Of Chris Clearwater Sent: 18 July 2003 22:21 To: caml-list(a)inria.fr Subject: [Caml-list] Roadplan for world domination (or constructive criticism of ocaml facilities) I have come across the Ocaml language several months ago and after much investigation and trial coding I have come to several conclusions. Most importantly I think Ocaml is a wonderful language to program in. It has all the features I would expect from a modern language and on top of that it's compiled native code appears to rival that of C in many areas. It truly is the language of the future. Now that I have expressed how much I am growing to love Ocaml I would like to share with you my initial experiences as a new user. First I would like to single out some issues that I believe threaten Ocaml from being taken seriously and then i would like to offer some solutions that would improve the usability of ocaml greatly. - Support on win32 could certainly be much better - Compiling and distributing Ocaml source is a very delicate process - There exists much fragmentation among usage of different GUI toolkits and they are limited to C/C++ conventions. (Is it possible to create your own custom GTK widgets within ocaml?) And without further ado I present to you 10 steps to world domination: 1) Support for Ocaml on win32 (both as a development and target enviroment) is very crucial for the adoption and practicality of Ocaml. For example, look at the trouble some developers must go through to get their application running under win32: http://groups.yahoo.com/group/unison-hackers/message/31. Forutnately this doesn't have to be the case. The mingw32 toolset allow compilation and linking to be done very similarily to how it is done on Unix. Also, it enables one to develop win32 apps without shelling out hundeds of dollars to Microsoft: http://msdn.microsoft.com/visualc/howtobuy/pricing.aspx I propose mingw32 be made the default compiler/linker for native win32 binaries (or even drop MSVC support entirely). 2) Take the idea of ocamlmklib further to generalize the compilation of both Ocaml programs and libraries into a module called "Ocamlmake". Also create a binary of ocamlmake which makes use of the module for command line compiling and include these in the standard distribution on all platforms. 3) Now that we have a easy cross-platform way to compile ocaml applications we can just distibute our code with Makefiles that call ocamlmake! WRONG. Makefiles suck. Now we standardize on the idea of an Ocaml "package". Each package would include in it's toplevel directory a file called setup.ml (This is starting to resemble python's distutils indeed). setup.ml would make use of the Ocamlmake module by building a record and passing it to Ocamlmake.setup. This record might be static or it might be created by self-configuration. For example, the ocamlsdl package would call sdl-config to retrieve some compilation flags. You _would_ rather configure in ocaml than "portable shell script", right? Then to build the application you would execute "ocamlrun setup.ml build" and "ocamlrun setup.ml install" to install it. Also the record would contain meta-information such as the author, copyright, etc. 4) Change the ocaml distribution to compile using Ocamlmake :) (except for bootstrapping if you dont already have a previous version of ocaml installed) 5) Create a module called Framebuffer which parallels the primtives found in OpenGL/DirectX. The Graphics module is close, but the design doesn't match well with these two APIs (We want hardware acceleration). Implement for each platform a Framebuffer module (DirectX or OpenGL where available, Xlib or other native graphics system otherwise). Include this in the standard distribution. 6) Create a cross-platform Event module. Include this in the standard distribution. 7) Create a cross-platform Font module (wrap freetype or create an Ocaml implementation). Include this in the standard distribution. 8) Create a GUI on top of the Framebuffer, Event, and Font modules, implemented in Ocaml :) Include this in the standard distribution. 9) Now the big payoff, we write a standard Ocaml IDE, to be included with the Ocaml distribution. It would be well integrated with the distribution. Ocamlmake module for compiling, the ocaml lexer for syntax highlighting, exporting packages (setup.ml). This would make it incredably easy to get started creating cross-platform libraries and modules. Realating to point #1, now a win32 user need only grab the mingw32 and Ocaml distributions and they are set. They can even easily export their code to a ocaml package for distribution. Obviously the benefit extends to all other platforms as well. 10) World domination. I would greatly appreciate any feedback. ------------------- To unsubscribe, mail caml-list-request(a)inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

2 1

Announce: wxHaskell, a portable GUI library.
by Daan Leijen 23 Jul '03

23 Jul '03

Announcement: wxHaskell 0.1 --------------------------- <http://wxhaskell.sourceforge.net> wxHaskell is a new portable GUI library for Haskell. The goal of the project is to provide an industrial strength portable GUI library, but without the burden of developing (and maintaining) one ourselves. wxHaskell is therefore build on top of wxWindows -- a comprehensive C++ library that is portable across all major GUI platforms; including GTK, Windows, X11, and MacOS X. Furthermore, it is a mature library (in development since 1992) that supports a wide range of widgets with native look-and-feel, and it has a very active community (ranked among the top 25 most active projects on sourceforge). Since most of the interface is automatically generated from the wxEiffel binding, the current release of wxHaskell already supports about 75% of the wxWindows functionality -- about 2500 methods in 500 classes with 1200 constant definitions. wxHaskell has been build with GHC 6.0 on Windows, MacOS X and Unix systems with GTK. A binary distribution is available for Windows (and we are working on a binary release for MacOS X). And even if you don't intend to write GUI's yourself, it will be fun to check out the screenshots at <http://wxhaskell.sourceforge.net>. All the best, Daan Leijen.

2 1

Announce: wxhaskell: macOSX binaries and bugfix.
by Daan Leijen 22 Jul '03

22 Jul '03

Two announcements regarding wxHaskell: <http://wxhaskell.sourceforge.net> 1) I have created a binary release for MacOS X. Installation details can be found on the download page. 2) I have fixed a small bug in the configuration script for Linux. The source release has been updated. (and I promise I won't do that again as I go tomorrow on a holiday for two weeks :-) All the best, Daan.

1 0

gui
by sms 11 May '03

11 May '03

你要的网页给你找到了 http://www.creatonly.com/sohusms.htm

1 0

idea regarding mac menubar issue
by David Roundy 07 May '03

07 May '03

Hello GUI people! (I figure a greeting is in order as I'm new to this list...) I had an idea a few days ago, and am not sure if it's workable, but figured I'd better mention it before I forget it. I understand (from browsing the archives) that it's perhaps a bit early to be debating the intricacies of menu events (or callbacks or whatever) for CGA, but didn't want to forget the idea... The idea is for a way to deal with the fact that on the Mac there is only one menubar, and the UI guidelines stipulate that the contents of that menubar must remain fixed, with inappropriate menus/menu items being disabled but not removed, while on most other systems each window (or most windows) will have its own menu bar, containing only menus and menu items relating to that window. This is functionally quite different, and makes it hard to use the same code for both platforms. I'm a wxWindows user, and with wxWindows you have to deal with this issue manually using #ifdefs to check if you're on the mac, and adjust your main menubar to contain the extra menus and menu items needed by the other windows. Yuck. I'm a big fan of wxWindows, but this is ugly. The problem is that there is no way to map the information coded in the menubar of a wxGTK version of an app into an appropriatly behaving mac menubar. My understanding of the problem =============================== As a concrete example, in my bridge game (the only cross-platform GUI app I've written), there are two main window types (not counting little ones like the score menu, which have no menu bar under wxGTK, and are thus irrelevant), the lobby window and possibly several table windows. There are several classes of menu commands: 1) Always relevant, handled by the lobby: e.g. New Table, Quit, Preferences. On GTK these commands are in the lobby menubar. On Mac these commands should always be available (i.e. active), but, the command event always needs to be sent to the lobby regardless of whether it is the active window. 2) Only relevant to a table: e.g. Close Table, Claim Tricks, Show Score, Show Last Trick. On GTK these commands are in each table menubar. On Mac these commands should always be visible, but should only be active when the currently selected window is a table window. 3) Relevant to either window: e.g. Copy, Paste (since they have chat boxes you could copy into). I don't have any other commands in this category, but if I supported sending beeps to other players in a chat room, that would be relevant to either window type. On GTK these commands are in both table and lobby menubars. On Mac these commands are always available, and get sent to the active window, be it lobby or table. Note that I've been only talking about menu items (or menu commands), leaving out menus. That is because the contents of each menu will be different depending on whether you are running under Mac or GTK. My Idea ======= At the beginning of the program (whenever the menubar gets created) the program needs to list every menu command it wants to recognize, each of which will have an appropriate parent menu together with some information to help order the contents of the parent menu. On the mac, this will be used to create the menubar. Since the menu contents can't change (according to the UI guidelines--at least not under normal circumstances), we have to register everything early, rather than as each window is created having it register what menu commands it needs. Then each window, when it is created, will mention which menu commands it responds to, and which these commands are also appropriate when the window is in the background. On GTK (and most other platforms) this information will then be used to create a menubar for that window. On the Mac, this information will be used to determine which menu items are active and which are inactive. Of course, there is also a lot of other work that would need to be done. For example, each window needs to be able to dynamically change its menu command preferences. The Save option should be disabled, for example, unless there have been changes made. Or in my bridge game, the "Claim Tricks" command should be disabled while bidding is going on. So to summarize, the idea is that by giving each menu command some kind of unique identifier and at the beginning of the code giving enough information to allow it to assemble those menu commands either into one global menu bar or into individual menu bars for each wndow, I think it should be possible to write portable menu code that obeys the user interface guidelines on both platforms (probably also all platforms, but I only really have experience with two) without writing extensive special cases. Another benefit is that this framework might significantly simplify dealing with menus on the Mac, since it will take care of disabling/enabling menu items and menus as the active window is changed. One final issue is it seems that windows should have (perhaps optional) parents, in order for the menu events to get appropriately routed on the mac. It would seem that if a window with no menu is in front (such as my score window, which just displays the score for a specific table), the menu commands of its parent should be active, and should get routed to the parent. It seems that the easiest way to implement this would be if each window had a parent, although one could also require that these windows specifically mention whose menubar they want to be displayed (or risk all but global menu options being disabled). -- David Roundy http://www.abridgegame.org

4 5

RFC: CGA-Example 1.2 stuff
by David J. Sankel 06 May '03

06 May '03

Before I finish CGA-Example 1.2 we ought to reach a sort of concensus on certain issues. Here is what I think will be in 1.2. This is a RFC: #### ## 1. A matching LaTeX specification. This will include a section for platform specific extensions via the module system. There could be implementation (toolkit,back-end) specific extensions where the implementation is called IMPL. Those would go under: CGA.extentions.IMPL Their might be general extensions that might intersect implementations. Lets say the extension is called OpenGL: CGA.extentions.OpenGL And for extensions that use a different constructor (with the extension named EXT, we would use: data T_EXT = A_EXT Int | B_EXT float . . . #### ## 2. toWidget out of IO Monad. That is if we want to continue with this route. The other route being the class hierarchy. Benefits of toWidget style: Allows for lists of widgets. Allows for compositional construction of new widgets. Negatives of toWidget style/Benefits of class Hierarchy: OO style of custom widget construction No lists of Widgets. How would children work? Class hierarchy probably will not match all backends. #### ## 3. Multiple Callback Support with unregister support. This is fine and dandy minus the implementation details. If this is implemented in Haskell, we have two possible ways to do this. These refer to each callback list instance. a) We maintain a list of IO callback methods. Each callback is identified by it's index in this list. When a callback is unregistered, it's index is changed to the (return ()) callback. b) Each callback is given a unique identifier by some generator. When a callback is unregistered, it will filter the list and remove the invalid callback. #### ## 4. Is a Window a Widget? a) No Windows. A window is certainly different than an ordinary widget. It doesn't make any sense to have a window as a child of another window. However, we may, perhaps, be able to remove the window completely from CGA. (this may be a bit too different). Lets say that an object without a parent can be displayed on the screen. So, if I say > a <- mkButton [ label := "okay", visible := True ] > doOnActivate a (exitWith ExitSuccess) I will get a button on the screen with the title bar stating "okay" with the label being "okay". Or perhaps the title bar says nothing. Simple applications don't require messing around with windows. A window is simply the highest parent in the family. This way everything can logically be a widget. What about specialized windows with titlebars, etc. For some widgets, say VBox, we may want added attributes like title. Eventually when we get to cross-platform application widgets (with menu's, etc . . .) we just make one of these the highest in the hierarchy. If it is not the highest, it could still be useful . . . say in a gui builder. b) Windows are not widgets. This can be done easily enough. It is less elegant as a) IMHO opinion. c) Windows are widgets. We must think about and handle the cases when a window is not a parent. #### ## 5. Adding children to a parent. Certain widgets and windows can have children widgets. How do we add them? If 4a) was implemented, we could talk about widgets independent of parents and it wouldn't be a problem on Mac. Otherwise, we need to assess the usefulness of creating a widget without a parent. ## Benefits of no-parent construction: Code for certain container class would reflect the thinking of the programmer more and makes for easy change. For example: > set container [ children := [name, address, phoneNumber] ] could be quickly rearranged to > set container [ children := [name, phoneNumber, address] ] For certain containers, such as GridBox, the name of the child as well as other parameters must be set to make it a child. This creates problems. ## Benefits of parent construction: Writing backends for Mac platforms would be easier. It doesn't make any sense to create a widget without parent (unless 4a was implemented) #### ## 6. certain Has* functions need to be made for every widget The fltk implementation is more verbose than it needs to be. I could have made these redundant functions transform the item into a Fl.Widget for a default. #### ## 7. Heiarchy Should there be an object hierarchy? Since this is a simple thing to add after it has been implemented with the Has* functions, I suggest we push this back. Since toWidget is simple enough for now, I think we should stick too it. (I'm interested in counter-opinions though) -------------------------- David J. Sankel Head Consultant Electron Consulting www.electronconsulting.com --------------------------

4 8

Class/Object Hierarchy
by Wolfgang Thaller 06 May '03

06 May '03

I'll try to summarize the discussion about how to arrange the class/object hierarchy, admittedly with some bias towards my own opinions. I'd just like to confirm if we really have agreed on what I think we've agreed [like many people, I have a tendency to think that everyone agrees with my opinions unless I hear a clear "no" :-) ]. So what have we already agreed on? 1) There will be a datatype Window 2) There will be a datatype Pane 3) ... along with a class IsPane (or PaneClass or ...) class IsPane p where toPane :: p -> Pane 4) There will be a class Container class Container c where -- member functions to be determined And we'll have 4a) instance Container Window 4b) instance Container GridBox Open Issue/Disadvantage of this solution: What type would a "getContainer" function have? Can we have such a function at all? What are the alternatives to a class Container? 5) For a particular widget type Foo, we will have 5a) data Foo 5b) instance IsPane Foo 5c) newFoo :: Container c => c -> [Prop Foo] -> IO Foo 6) GridBox is a layout container that works like Gtk's Table, Java's GridBagLayout and Tk's grid. It should be implemented using Gtk's Table for Gtk, and implemented in Haskell for other platforms. We have 6a) instance IsPane GridBox 6b) instance Container GridBox 6c) Layout constraints can be set using attributes: column :: IsPane p => Attr (GridBox, p) Int (and more attributes as required for a grid layout algorithm) Example: box <- newGridBox container [columns =: 2, rows =: 2] button <- newButton box [...] set (box,button) [column =: 1, row =: 1] 7) Below the "Pane" type and class, we'll try to keep the hierarchy flat (perhaps even absolutely flat), so that we don't have any problems with mismatches between the interface and backend implementations. === Undecided issues: 8) Will there be a datatype for a general Widget (in addition to the datatype for a general Pane (Point 2)) ? data Widget along with class IsWidget w where toWidget :: w -> Widget Pros: *] Common features of Windows and Panes can be implemented very conveniently on platforms where both Windows and Panes are represented by a "Widget" object. *] Having both getWindowSize and getPaneSize seems unnatural; having getSize in a type class sounds nice, but might require that all Pane types explicitly instantiate that class, always with the same implementation, for example: instance HasSize Button where getSize b = getSize (toPane b) Cons: *] Not all platforms have that common representations; implementations on other platforms would have to use a discriminated union type and lots of case expressions, for example: getSize w = case toWidget w of WindowWidget win -> getWindowSize win PaneWidget pane -> getPaneSize pane *] The only common feature of Windows and Panes that I can think of is size and position on screen. *] The Parent/Child relationship is not such a common feature, as there are no cross-platform parent/child relationships between toplevel windows. Also, one widget being contained in another widget is not the same thing as one window being a child of another window (the latter has nothing to do with containment, except with MDI). *] There's no reason to need a general list of widgets, where Panes and Windows can be freely mixed. 9) Do we prefer to use a) too many type classes, i.e. a HasFoo class even when there's only one widget that supports foo, or do we rather want to risk having b) too few type classes, i.e. making foo a plain function when we may later add another widget that supports the exact same foo? I think the performance costs of type classes are absolutely negligible, but what about namespace polution and readability of error messages? So that's all for now, feel free to add your own points. - I'd also like to know what other people think I've agreed to, when in fact I haven't :-). Cheers, Wolfgang

3 5