(add a link)
|Line 13:||Line 13:|
== Examples ==
== Examples ==
Revision as of 22:59, 7 June 2013
LGtk is a lens-based API for Gtk. LGtk is built on Gtk2Hs.
Most Haskellers would like to use a mature FRP-based API for creating graphical user interfaces. FRP may not be the best tool for special user interfaces, like interfaces which consists of buttons, checkboxes, combo boxes, text entries and menus only. LGtk has a lens-based API which fits better these user interfaces.
3.1 Hello World
main = runWidget $ label $ return "Hello World!"
The following applications presents an entry and a label below of it. When a text is entered in the entry, the label is changed to the entered text.
main = runWidget $ action $ do r <- newRef "enter text here" return $ vcat [ entry r , label $ readRef r ]
A crutial feature of LGtk is that you cannot change the value of references in this monad (you can read them though).
Two entries of integers and a label which shows the sum:
main = runWidget $ action $ do r1 <- newRef (12 :: Integer) r2 <- newRef 4 return $ vcat [ entryShow r1 , entryShow r2 , label $ liftM show $ liftM2 (+) (readRef r1) (readRef r2) ]
3.4 Complex examples
You can find more complex examples in the source code of LGtk. More examples will be presented here also.
Features of lgtk-0.5
- The API is closed, you can safely use any constructs as far as you obey the documented laws.
- Support for asynchronous events. Using LGtk is a safe way for writing multithreaded Gtk applications.
- The semantics is getting stable but it is not yet documented.
- Add an efficient implementation for LGtk. LGtk has only a reference implementation currently.
- Add support for styles (layout, colors, etc).
- Support more Gtk constructs.
5 Demo application
You can try the demo application with the following commands:
cabal install gtk2hs-buildtools cabal install lgtk lgtkdemo
- Documentation fixes and cleanup
- Try to support Haskell Platform 2012.4.0.0
- Do not use monadic lenses any more.
- Support for asynchronous events.
- Lazily created tabs.
- Unactive tabs are really unactive (event handlers are detached).
- File references watch the files. When the file changes, the GUI is updated.
- References with inherent identity (makes defining auto-sensitive buttons easier)
- Experimental support for colored buttons.
- More examples in the demo application.
- Lots of inner changes.
Related Stackoverflow questions: