Personal tools

WxHaskell

From HaskellWiki

(Difference between revisions)
Jump to: navigation, search
Line 44: Line 44:
 
The [[WxHaskell/Install | wxHaskell install]] page contains details of different people's experience in compiling and installing wxHaskell against various versions of wxWidgets on various platforms.
 
The [[WxHaskell/Install | wxHaskell install]] page contains details of different people's experience in compiling and installing wxHaskell against various versions of wxWidgets on various platforms.
  
== Tips ==
+
== Tips and tricks ==
  
 
# Getting Started:
 
# Getting Started:
Line 66: Line 66:
 
#* for ghci usage download EnableGui.hs from wxhaskell.sourceforge.net/download/EnableGUI.hs and <br /><code> ghc -fffi -package wx EnableGUI.hs<br /> ghci -package wx HelloTest.hs EnableGui.hs<br />-- followed by :m +EnableGUI and <br />enableGUI >> main</code>  
 
#* for ghci usage download EnableGui.hs from wxhaskell.sourceforge.net/download/EnableGUI.hs and <br /><code> ghc -fffi -package wx EnableGUI.hs<br /> ghci -package wx HelloTest.hs EnableGui.hs<br />-- followed by :m +EnableGUI and <br />enableGUI >> main</code>  
  
== A Short Guide ==
+
=== Other tips ===
  
It is helpful to a get a grip on three basic concepts: Widgets, Layout and Events.
+
==== Idle event ====
  
=== Widgets ===
+
Use the [[WxHaskell/Idle event | idle event]] for automation.
Widgets are the basic components of any GUIs.  They include buttons, radio boxes, frames and what not.  There are essentially two kinds of widgets: windows and controls.  Windows are widgets that contain other widgets.  Note: what you might normally think of as a window, i.e. that big thing with the close, minimise, maximise buttons on your OS in wxHaskell is a special kind of window called a "frame".
+
 
+
We define windows by calling some function (for example, ''frame'') with a list of attributes.  Here is a example which creates a frame with the title bar "Hello!":
+
 
+
hello
+
  = do f    <- frame    [text := "Hello!"]
+
 
+
The more interesting widgets are controls such a buttons and check boxes.  We define controls almost the same way as windows, by calling some function (for example, ''button'') with a window and a list of attributes:
+
 
+
hello
+
  = do f    <- frame    [text := "Hello!"]
+
        quit <- button f [text := "Quit"]
+
 
+
The relevant documentation:
+
  * http://wxhaskell.sourceforge.net/doc/Graphics.UI.WX.Controls.html
+
  * http://wxhaskell.sourceforge.net/doc/Graphics.UI.WX.Window.html
+
 
+
=== Layout ===
+
[[WxHaskell/Layout | Layout]] means telling wxHaskell how to arrange your widgets with respect to each other.  It is something you would normally do after you have defined all your widgets.
+
 
+
We won't go into much detail here because the Haddock-generated documentation is very helpful here, but here is a trivial example of layout where all we do is stick the quit button in the frame.  Notice how layout is just an attribute of the frame widget.
+
 
+
hello
+
  = do f    <- frame    [text := "Hello!"]
+
        quit <- button f [text := "Quit"]
+
        set f [layout := widget quit]
+
 
+
  * http://wxhaskell.sourceforge.net/doc/Graphics.UI.WX.Layout.html
+
 
+
==== Scrolled windows ====
+
 
+
Widgets (for example, listboxes) will automatically create scrolled windows for you.  You only need to deal with them if you are working with bitmaps.
+
 
+
 
+
==== XRC ====
+
How do you use XRC-Files with wxHaskell? Is it possible?
+
 
+
''- I also very much would like to know this. Anyone?''
+
 
+
:''There isn't a way, but it sounds like it might be a fun library to build''
+
 
+
=== Events ===
+
Events are what joins your widgets to the rest of your code.  Whenever a user manipulates a widget (e.g. presses a button), an event is triggered.
+
If you set the appropriate attributes, you can cause these events to call some piece of Haskell code.  In the following example, we set the "on command" attribute to close the frame f.
+
 
+
hello
+
  = do f    <- frame    [text := "Hello!"]
+
        quit <- button f [text := "Quit", on command := close f]
+
        set f [layout := widget quit]
+
 
+
* http://wxhaskell.sourceforge.net/doc/Graphics.UI.WX.Events.html
+
 
+
==== Idle Event ====
+
Use [[WxHaskell/Idle event | idle event]] for automation.
+
 
+
== Tricky problems and their solutions ==
+
  
 
=== Long computations ===
 
=== Long computations ===

Revision as of 18:28, 5 August 2008

Wxhaskell-black-small.png

Contents

1 What is it?

wxHaskell is a portable and native GUI library for Haskell. The goal of the project is to provide an industrial strength GUI library for Haskell, but without the burden of developing (and maintaining) one ourselves.

wxHaskell is therefore built on top of wxWidgets – 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 the native look-and-feel, and it has a very active community (ranked among the top 25 most active projects on sourceforge).

2 Status

Since the core interface is generated automatically from the wxEiffel binding, about 90% of the wxWidgets functionality is already supported, excluding more "exotic" widgets like dockable windows. Most work is currently directed into writing a Haskellized version of the wxWidgets API. The library currently supports Windows, GTK (Linux) and MacOS X.


3 News

23 March 2008</dt>
wxHaskell 0.10.3 is released.</dd>
20 January 2007</dt>
wxHaskell has a new set of maintainers, led by Jeremy O'Donoghue. We are working on a release for version 0.10, with Uni code support, a Cabalized build process and more. All recent development is taking place under a new darcs repository (darcs get http://darcs.haskell.org/wxhaskell).</dd>

4 Documentation

5 Installation

The wxHaskell install page contains details of different people's experience in compiling and installing wxHaskell against various versions of wxWidgets on various platforms.

6 Tips and tricks

  1. Getting Started:
  2. Text:
    • retrieving the text of a TextCtrl: mytext <- get mytextEntry text
    • staticText misbehaves on resize: make sure that you are giving the widget enough space... for example, if you want a one-line staticText, you should
      • use hfill on the staticText
      • not use hfill (or hfloat...) or any other widgets in the same row
  3. Layout:
    • Don't bother looking at the the examples yet, the API is better for this
    • See the Haddock-generated documentation for Graphics.UI.WX.Layout
    • Got layout troubles? Packing things inside yet another panel seems to help sometimes
  4. Scroll Bars:
    • scrollbars are just windows. You create a scrollFrame, and any widgets you want inside the scrollbars, you make this scrollFrame their parent
    • see samples/wx/ImageViewer.hs
    • the following widgets (controls) already include scrollbars : listBox
  5. Mac OS X (Darwin)
    • for ghci usage download EnableGui.hs from wxhaskell.sourceforge.net/download/EnableGUI.hs and
      ghc -fffi -package wx EnableGUI.hs
      ghci -package wx HelloTest.hs EnableGui.hs
      -- followed by :m +EnableGUI and
      enableGUI >> main

6.1 Other tips

6.1.1 Idle event

Use the idle event for automation.

6.2 Long computations

Scenario: you've got a looooooong computation and you want to update a progress bar or you want to have a 'STOP' button which aborts the computation

Solution:

  • wxcApp(Safe)Yield

FIXME: elaborate on this!

6.3 Managing multiple windows

Scenario: you have a main window MAIN with some information. You want to create a secondary window PARAMS in which the user edits some configuration stuff. When the user closes PARAMS, the window MAIN should be updated to reflect the new settings.

You have some code which looks like

set paramsButton [ on command := do createParamsWindow
                                    updateMainWindow ]

Problem: MAIN is not updated... at least, not until you call PARAMS a second time.

Observations:

  • This is NOT a problem with Haskell laziness

Explanation: updateMainWindow tries to read the new configuration value, but it does not succeed, because no configuration values have changed. Why not? Simpler than it looks: all the createParamsWindow function does is creates a window with some widgets, assign some commands to said widgets, and return. There's nothing in the createParamsWindow code that says the function should only return when PARAMS has been closed.

Solution: Pass createParamsWindow a function which updates the MAIN window:

set paramsButton [ on command := do createParamsWindow updateMainWindow ]

When the user closes PARAMS, one of the final things it should do is call this update function

7 External links

8 See also