===================== CGA-example version 1.1 ===================== ===================== Overview :: This is an example of a low-level binding to a c++ GUI library and a mid-level CGA abstraction over it. This was created primarily to spark discussion in the gui@haskell.org mailing list and secondarily to provide a simple example that can be compiled using ghc without any language extensions. I encourage those who code, to implement their ideas for the Common GUI API using this simple framework. This would allow all reviewers to understand exactly what you are talking about by running your examples. Fltk was chosen for its simplicity and portability. I didn't use an existing library because I wanted a short example where the source code is easy to comprehend at all levels. ===================== Changes :: v1.1 -- Using Heiarchy extention for module naming. Completed CGA version of Box, Button, Window, and Widget. Now using the agreed callback format. Initial child handeling support. Using class-per-function naming. Using MVar's in example CGA application for simplicity. ===================== Questions :: 1) How does the interface look in Test_midlevel.hs? Is there any critiques in regard to using this style in CGA (Common GUI API)? 2) Haskell has one namespace, the global one. Since there would be a lot of function names and attributes in CGA, their names should be well thought out. Is there any ideas on how to handle this? 3) How should children be handled? I used both an attribute and a seperate function in this implementation. 4) What do you think is important to have in the next version of CGA-example? ===================== Running :: To run the examples, one needs a standard Haskell compiler with ffi (ghc) and fltk installed (http://www.fltk.org). run make. If necessary, change the makefile to modify for your configuration. Fl-stubs/* -- These are the stubs that are used to bind the c++ library to c functions. This is required because the Haskell ffi standard does not specify any conventions for C++. Fl.hs Fl/* -- These contain the bindings to the stub files. They also provide a low-level interface for the fltk GUI toolkit. Test_lowlevel.hs -- This is a simple program demonstrating use of the low-level binding. Attributes.hs -- This code was taken from the htoolkit cvs server. Simple modifications were made to suit our purposes. CGA.hs CGA/* -- This is the Midlevel, CGA code wrapping the low-level Fl interface. CGA/CommonAttributes.hs CGA/CommonMembers.hs CGA/CommonSignals.hs -- these are the support files for the one-class-per-function style as proposed on gui@haskell.org. Test_midlevel.hs -- This is the same simple program as Test_lowlevel.hs except it uses CGA instead of Fl. ===================== Cheers, David J. Sankel
===================== CGA-example version 1.1 =====================
Great Stuff!
1) How does the interface look in Test_midlevel.hs? Is there any critiques in regard to using this style in CGA (Common GUI API)?
Looks nice. What I don't like: *) Why is toWidget in the IO monad? Instead of a <- toWidget hello set window [ children =: [a], visible =: True ] I'd rather write set window [ children =: [toWidget hello], visible =: True ] *) No dynamic layout yet. If we have a container that does dynamic layout similar to Java's GridBagLayout, then of course we don't want to set size and position attributes for each widget. We'd set row, column, row span and column span attributes instead. Those layout constraints are not really attributes of the widget itself. Rather, they should perhaps be passed along with addChild. But right now I can't think of how to do it without multi-parameter type classes (we wanted to stick to H98, didn't we?): class HasAddChild a c where addChild :: IsWidget b => a -> b -> c -> IO () class HasChildren w c where children :: Attr w [(Widget,c)] ... where c would be a set of coordinates, or a set of row & column numbers, depending on what kind of container we are in. In a container with dynamic layout, position and size would still make sense as a read-only attribute, but explicitly setting the position would be questionable.
4) What do you think is important to have in the next version of CGA-example?
Some framework for dynamic layout, see above.
I encourage those who code, to implement their ideas for the Common GUI API using this simple framework. This would allow all reviewers to understand exactly what you are talking about by running your examples.
I've already started compiling fltk... Cheers, Wolfgang
There is an obvious bug in the update function ~: (I have a simple program to test in case someone is not convinced): the update function performs the "getter" and "setter" operations sequentially; this is a critical section and should be protected by mutual exclusion in a multithreaded environment. V.
--- Nick Name
There is an obvious bug in the update function ~: (I have a simple program to test in case someone is not convinced): the update function performs the "getter" and "setter" operations sequentially; this is a critical section and should be protected by mutual exclusion in a multithreaded environment.
Please post code. It speaks much better to me than English ;-). And a fix, perhaps? David J. Sankel
participants (4)
-
David J. Sankel -
David Sankel -
Nick Name -
Wolfgang Thaller