GLFW-b: GLFW bindings

[ bsd3, graphics, library ] [ Propose Tags ]

Bindings to GLFW, a free, open source, multi-platform library for creating OpenGL contexts and managing input, including keyboard, mouse, joystick and time.

GLFW-b works on Windows, Mac OS X, and many Unix-like operating systems.

Please see ( for information about how these bindings differ from the ones in the GLFW package (

For more information about the library on which these bindings are based, please see

[Skip to Readme]




Note: This package has metadata revisions in the cabal description newer than included in the tarball. To unpack the package including the revisions, use 'cabal get'.

Maintainer's Corner

For package maintainers and hackage trustees


Versions [RSS] 0.0.1, 0.0.2,,,,,,,,,,,,,,,,, 1.0.0, 1.0.1, 1.0.2, 1.1.0, 1.2.0, 1.2.1, 1.3, 1.4, 1.4.1, 1.4.2, 1.4.3, 1.4.4, 1.4.5, 1.4.6, 1.4.7,,,,,,,,,,,
Dependencies base (>=4 && <4.6) [details]
License BSD-3-Clause
Author Brian Lewis <>
Maintainer Brian Lewis <>
Revised Revision 1 made by HerbertValerioRiedel at 2019-01-07T10:49:37Z
Category Graphics
Source repo head: git clone git://
Uploaded by BrianLewis at 2011-11-14T04:40:05Z
Distributions LTSHaskell:, NixOS:, Stackage:
Downloads 46903 total (137 in the last 30 days)
Rating 2.5 (votes: 3) [estimated by Bayesian average]
Your Rating
  • λ
  • λ
  • λ
Status Docs uploaded by user
Build status unknown [no reports yet]

Readme for GLFW-b-

[back to package description]

Differences between GLFW and GLFW-b 2011.03

  • GLFW binds to version 2.6 of the GLFW C library. GLFW-b binds to 2.7.

  • Some GLFW functions return OpenGL {Gettable,Settable}StateVars. I don't like this because it adds an extra step to extract a value and causes GLFW to be dependent on OpenGL. GLFW-b doesn't depend on OpenGL.

  • GLFW sometimes depends on GLFW C library internally defined values. GLFW-b doesn't. For example, GLFW-b doesn't assume that GL_FALSE = 0. I don't think this makes a difference in practice, but it makes me feel better.

  • GLFW sometimes assumes that certain Haskell types are equivalent to certain C types, e.g. Int and int. GLFW-b doesn't. GLFW-b always uses the appropriate type from Foreign.C.Types. I don't think this makes a difference in practice, but it makes me feel better.

  • GLFW contains workarounds for a bugs in GHC < 6.10 FFI. GLFW-b doesn't.

  • GLFW's API is pretty faithful to the C API. GLFW-b prefers to use full words and self-explanatory function names.

  • In GLFW-b, registering hints and opening a window are combined into one step.

  • GLFW has support for loading textures and rendering strings. GLFW-b doesn't.