Announce: wxHaskell 0.2
Announcement: wxHaskell version 0.2 ---------------------------------------------------------------------- <http://wxhaskell.sourceforge.net> The new release has (improved) support for tree controls, list controls, toolbars, splitter windows, sliders, gauges, and bitmap buttons. Screenshots of these widgets on different platforms have been added to the website. Furthermore, there are numerous small bug fixes, especially for wxGTK. A list of non-compatible changes is attached at the end of this mail. ---------------------------------------------------------------------- wxHaskell is a 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 -- 2766 methods in 505 classes with 1279 constant definitions. wxHaskell has been build with GHC 6.0/6.01 on Windows, MacOS X and Unix systems with GTK. A binary distribution is available for Windows and 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. ps. More funny statistics: the wxWindows libraries have been downloaded over a million times at sourceforge! The Python binding to wxWindows (wxPython) about 600.000 times, and the Haskell binding to wxWindows about 100 times :-) ---------------------------------------------------------------------- Breaking changes to version 0.1: - Renamed the "WXH" layer to "WXCore".
import Graphics.UI.WXCore instead of import Graphics.UI.WXH
- Changed the interface of menu items a bit. The label and help text is now supplied via attributes:
medit <- menuPane [text := "&Edit"] mfont <- menuItem medit [text := "&Font...\tCtrl+F" ,help := "Set the font"]
I just had a look at wxHaskell (GHC from CVS, about a week old, SuSE Linux 8.2 on x86). A few remarks: * It would be nice if the directory created by unzipping wxhaskell-src-0.2.zip contained a version number. * It would be even nicer if wxhaskell-doc-0.2.zip unzipped into a *single* directory. * You need `-package parsec' for linking wxdirect nowadays. * When HelloWorld terminates, it segfaults in wxVariant()'s destructor. I have no idea what's going on here, but I can only repeat my warnings stated some time ago: Mixing a C++ library with pure C (= GHC's code) is a highly delicate, platform/compiler dependent and fragile thing to do... * The package configuration should include linker flags for the path of libwxc.so, otherwise a non-superuser has to fiddle around with LD_LIBRARY_PATH and the like. Furthermore, the library documentation says: "Portability: portable", but this is not the case at all, wxHaskell uses quite a few extensions (apart from the FFI, which can be considered portable nowadays): * wxcore/src/Graphics/UI/WXCore/IntMap.hs fiddles around with unboxed values and GHC interna for performance reasons. Is this really necessary? (Apart from that, it triggers a bug in GHC's new Lexer :-} * The default declaration of setBitMask in wx/src/Graphics/UI/WX/Types.hs uses a scoped type variable. This could probably be rewritten to something more portable. * wx/src/Graphics/UI/WX/Attributes.hs uses existentially quantified data constructors (:=, :~, ::=, and ::~) for purely aesthetical reasons. * wx/src/Graphics/UI/WX/Classes.hs uses MPTC with functional dependencies. * Type synonyms in instance heads + complex instance heads are quite pervasive: wx/src/Graphics/UI/WX/{Events,Window,Frame,Menu,Timer,Draw,Controls,Dialogs}.hs wxcore/src/Graphics/UI/WXCore/Layout.hs I don't want to sound too negative, Daan has done an impressive job, but I'm a bit concerned about all this non-portable stuff when we are planning to use wxHaskell as the basis for our GUI efforts. Cheers, S.
Hi Sven,
the library documentation says: "Portability: portable", but this is not the case at all, wxHaskell uses quite a few extensions (apart from the FFI, which can be considered portable nowadays):
wxHaskell consists of two layers: WXCore and WX. The WXCore layer is supposed to be totally Haskell98 compatible (or really easy to make compatible). The WX layer is a nice haskellized version of the wxWindows API on top of WXCore that uses extensions.
* wxcore/src/Graphics/UI/WXCore/IntMap.hs fiddles around with unboxed values and GHC interna for performance reasons. Is this really necessary? (Apart from that, it triggers a bug in GHC's new Lexer :-}
No, it is not. Actually on <http://www.cs.uu.nl/~daan/ddata.html> you can find a Hugs98 and "standard" haskell98 version. I just used this one as I only use GHC but it can easily be replaced.
* The default declaration of setBitMask in wx/src/Graphics/UI/WX/Types.hs uses a scoped type variable. This could probably be rewritten to something more portable.
Thanks for the hint. I'll remove the type declaration.
* wx/src/Graphics/UI/WX/Attributes.hs uses existentially quantified data constructors (:=, :~, ::=, and ::~) for purely aesthetical reasons.
Yes, I am considering changing it to "=:" operators, that look less nice, but remove the dependency on rank-2 polymorphism. However, I haven't removed them yet as 1) not enough people complained, 2) any serious haskell compiler supports "forall" now, and 3) the (:=) operator looks *really* good, and 4) I depend on more devious things already which are harder to avoid, namely:
* Type synonyms in instance heads + complex instance heads are quite pervasive:
This is a devious thing to do, but totally unavoidable given the way I model inheritance with phantom types. I have considered using type classes to model the inheritance but that leads to a) other dependencies on extensions, b) hard to understand error messages, and c) a much more complex model. (See Andre Pang's master thesis for a ingenious way to model full inheritance) On the other hand, phantom type inheritance is easy *and* using type synonyms in instance heads is *very* convenient (a huge improvement compared to all the instance declarations I had to write for GIO). (So, I guess I am making a case for supporting this extension in future Haskells as it is so useful).
* wx/src/Graphics/UI/WX/Classes.hs uses MPTC with functional dependencies.
Hmm, yes, but these could be removed -- they are not very important.
I don't want to sound too negative, Daan has done an impressive job, but I'm a bit concerned about all this non-portable stuff when we are planning to use wxHaskell as the basis for our GUI efforts.
I share your concerns. However, keep in mind that WXCore is Haskell98 + FFI, and that only the nicified abstraction WX uses extensions. That is, anyone can build another nicified abstraction that is H98 compatible. However, it seems that for "real" libraries, one wants a bit more power. In the end though, I would like wxHaskell to be an open community effort and not to be "daan's" library. In that sense, anyone can change the libraries interface if enough people support that. I am not emotionally attached to my design and will certainly support people that want to change or fix the library (especially given my lack of time to spend on this project :-). All the best, and thanks for your comments, Daan.
Cheers, S.
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Hi Sven, (I'll reply to the portability issues in a separate mail)
* It would be nice if the directory created by unzipping wxhaskell-src-0.2.zip contained a version number.
* It would be even nicer if wxhaskell-doc-0.2.zip unzipped into a *single* directory.
* You need `-package parsec' for linking wxdirect nowadays.
Thanks for the hints. I'll look into it for a future version. I will not actively support CVS GHC's though -- that will be too much work :-)
* When HelloWorld terminates, it segfaults in wxVariant()'s destructor. I have no idea what's going on here, but I can only repeat my warnings stated some time ago: Mixing a C++ library with pure C (= GHC's code) is a highly delicate, platform/compiler dependent and fragile thing to do...
I am quite sure that this has nothing to do with C vs. C++ :-) (I am not linking at all with C++ directly -- instead I am using extern C wrappers that are used in a separate dynamic link library with their own C++ runtime system. This is just like calling any other systems library. ) The segfault is really weird though -- it might be that you started "main" twice from GHCi (a known bug in wxGTK), that your GHC is broken, that you use an old GTK, anything really.... :-(
* The package configuration should include linker flags for the path of libwxc.so, otherwise a non-superuser has to fiddle around with LD_LIBRARY_PATH and the like.
I am fairly hesitant here -- this means that I need two different package description files -- one for binary installs and one for developer installs. I'll look into it, but since I am not a real unix wizard, maybe you can tell me offline what you exactly need/want. All the best, Daan.
On Tue, Sep 16, 2003 at 03:24:50PM +0200, Daan Leijen wrote:
Announcement: wxHaskell version 0.2
Thanks for the release. 0.2 seems to build much better on Linux. :) I built an rpm package with ghc-6.0.1 for wxGTK2 and put it at http://juhp.dyndns.org/jens/haskell/ for now. They should be available from later http://haskell.org/~petersen/rpms/wxhaskell/ (current public_html seems to be disabled on haskell.org). Jens
Jens Petersen wrote:
http://haskell.org/~petersen/rpms/wxhaskell/
(current public_html seems to be disabled on haskell.org).
Not so; you have a syntax error in your .htaccess (perhaps apache was upgraded and the syntax changed?). If you remove it or correct the error, your page will be served. --KW 8-)
Thanks for the release. 0.2 seems to build much better on Linux. :) I built an rpm package with ghc-6.0.1 for wxGTK2 and put it at
Thanks! I'll try it out and put it on sourceforge (if that is ok with you). I also like your naming scheme, I guess I should also include the ghc version and processor in the name of binary releases. (btw. what does the extra "-2" mean in the version? (like wxhaskell-ghc6.0.1-0.2-2.i386.rpm) -- Daan
http://juhp.dyndns.org/jens/haskell/ for now. They should be available from later http://haskell.org/~petersen/rpms/wxhaskell/ (current public_html seems to be disabled on haskell.org). Jens _______________________________________________ GUI mailing list GUI@haskell.org http://www.haskell.org/mailman/listinfo/gui
participants (4)
-
Daan Leijen -
Jens Petersen -
Keith Wansbrough -
Sven Panne