Versions |
0.1, 0.2, 0.2.1, 0.2.2, 0.2.3, 0.3, 0.3.1, 0.4, 0.4.1, 0.5, 0.5.1, 0.6, 0.6.1, 0.6.2, 0.6.3, 0.6.4, 0.7, 0.8, 0.9, 0.10, 0.11, 0.12, 0.13, 0.14, 0.15, 0.15.1, 0.15.2, 0.16, 0.17, 0.17.1, 0.17.2, 0.18, 0.19, 0.20, 0.20.1, 0.21, 0.22, 0.23, 0.24, 0.24.1, 0.24.2, 0.25, 0.26, 0.26.1, 0.27, 0.28, 0.29, 0.29.1, 0.30, 0.31, 0.32, 0.32.1, 0.33, 0.34, 0.34.1, 0.34.1, 0.35, 0.35.1, 0.36, 0.36.1, 0.36.2, 0.36.3, 0.37, 0.37.1, 0.37.2, 0.38, 0.39, 0.40, 0.41, 0.41.1, 0.41.2, 0.41.3, 0.41.4, 0.41.5, 0.42, 0.42.1, 0.43, 0.44, 0.44.1, 0.45, 0.46, 0.47, 0.47.1, 0.48, 0.49, 0.50, 0.50.1, 0.51, 0.52, 0.52.1, 0.53, 0.54, 0.55, 0.56, 0.57, 0.57.1, 0.58, 0.58.1, 0.59, 0.60, 0.60.1, 0.60.2, 0.61, 0.62, 0.63, 0.64, 0.64.1, 0.64.2, 0.65, 0.65.1, 0.66, 0.66.1, 0.67, 0.68, 0.68.1, 0.69, 0.69.1, 0.70, 0.70.1, 0.71, 0.71.1, 0.72, 0.73, 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 1.10, 2.0, 2.1, 2.1.1, 2.2, 2.3, 2.3.1, 2.3.2, 2.4 |
Change log |
CHANGELOG.md |
Dependencies |
base (<=5), brick, config-ini, containers, contravariant, data-clist (>=0.1), deepseq (>=1.3 && <1.5), dlist, microlens (>=0.3.0.0), microlens-mtl, microlens-th, stm (>=2.4), template-haskell, text, text-zipper (>=0.7.1), transformers, vector, vty (>=5.18.1), word-wrap (>=0.2) [details] |
License |
BSD-3-Clause |
Copyright |
(c) Jonathan Daugherty 2015-2018 |
Author |
Jonathan Daugherty <cygnus@foobox.com> |
Maintainer |
Jonathan Daugherty <cygnus@foobox.com> |
Category |
Graphics |
Home page |
https://github.com/jtdaugherty/brick/
|
Bug tracker |
https://github.com/jtdaugherty/brick/issues
|
Source repo |
head: git clone git://github.com/jtdaugherty/brick.git |
Uploaded |
by JonathanDaugherty at 2018-02-25T16:29:32Z |
brick
is a Haskell terminal user interface programming library in the
style of gloss. This means
you write a function that describes how your user interface should look,
but the library takes care of a lot of the book-keeping that so commonly
goes into writing such programs.
brick
exposes a declarative API. Unlike most GUI toolkits which
require you to write a long and tedious sequence of "create a widget,
now bind an event handler", brick
just requires you to describe your
interface using a set of declarative combinators. Then you provide a
function to transform your application state when input or other kinds
of events arrive.
Under the hood, this library builds upon
vty, so some knowledge of Vty
will be helpful in using this library.
Release Announcements / News
Find out about brick
releases and other news on Twitter:
https://twitter.com/brick_haskell/
Example
Here's an example interface (see programs/ReadmeDemo.hs
):
withBorderStyle unicode $
borderWithLabel (str "Hello!") $
(center (str "Left") <+> vBorder <+> center (str "Right"))
Result:
┌─────────Hello!─────────┐
│ │ │
│ │ │
│ Left │ Right │
│ │ │
│ │ │
└────────────────────────┘
Featured Projects
To get an idea of what some people have done with brick
, take a look
at these projects:
tetris
, an implementation of the Tetris game: https://github.com/SamTay/tetris
gotta-go-fast
, a typing tutor: https://github.com/hot-leaf-juice/gotta-go-fast
haskell-player
, an afplay
frontend: https://github.com/potomak/haskell-player
mushu
, an MPD
client: https://github.com/elaye/mushu
matterhorn
, a client for Mattermost: https://github.com/matterhorn-chat/matterhorn
viewprof
, a GHC profile viewer: https://github.com/maoe/viewprof
tart
, a mouse-driven ASCII art drawing program: https://github.com/jtdaugherty/tart
silly-joy
, an interpreter for Joy in Haskell: https://github.com/rootmos/silly-joy
herms
, a command-line tool for managing kitchen recipes: https://github.com/jackkiefer/herms
purebred
, a mail user agent: https://github.com/purebred-mua/purebred
2048Haskell
, an implementation of the 2048 game: https://github.com/8Gitbrix/2048Haskell
bhoogle
, a Hoogle client: https://github.com/andrevdm/bhoogle
Getting Started
Check out the many demo programs to get a feel for different aspects of
the library:
$ cabal new-build -f demos
$ find dist-newstyle -type f -name \*-demo
To get started, see the user guide.
Documentation
Documentation for brick
comes in a variety of forms:
Feature Overview
brick
comes with a bunch of batteries included:
Low-level stuff:
- Vertical and horizontal box layout widgets
- Basic single- and multi-line text editor widgets
- List widget
- Progress bar widget
- Simple dialog box widget
- Border-drawing widgets (put borders around or in between things)
- Generic scrollable viewports
- (And many more general-purpose layout control combinators)
Other killer features:
- Extensible widget-building API
- User-customizable attribute themes
- Type-safe, validated input form API (see the
Brick.Forms
module)
Brick-Users Discussion
The brick-users
Google Group / e-mail list is a place to discuss
library changes, give feedback, and ask questions. You can subscribe at:
https://groups.google.com/group/brick-users
Status
There are some places were I have deliberately chosen to worry about
performance later for the sake of spending more time on the design
(and to wait on performance issues to arise first). brick
is also
something of an experimental project of mine and some aspects of the
design involve trade-offs that are not entirely settled. In addition you
can expect this library to follow a principle of fearless improvement:
new versions will make (sometimes substantial) API changes if those
changes really do make the library better. I will place more importance
on getting the API right than on maintaining backwards compatibility.
brick
exports an extension API that makes it possible to make your own
packages and widgets. If you use that, you'll also be helping to test
whether the exported interface is usable and complete!
Reporting bugs
Please file bug reports as GitHub issues. For best results:
-
Include the versions of relevant software packages: your terminal
emulator, brick
, ghc
, and vty
will be the most important
ones.
-
Clearly describe the behavior you expected ...
-
... and include a minimal demonstration program that exhibits the
behavior you actually observed.
Contributing
If you decide to contribute, that's great! Here are some guidelines you
should consider to make submitting patches easier for all concerned:
- If you want to take on big things, talk to me first; let's have a
design/vision discussion before you start coding. Create a GitHub
issue and we can use that as the place to hash things out.
- Please make changes consistent with the conventions I've used in the
codebase.
- Please adjust or provide Haddock and/or user guide documentation
relevant to any changes you make.