A declarative Unix terminal UI programming library written in Haskell
Go to file
Jonathan Daugherty a2191bf219 Update README
2015-07-21 18:30:33 -07:00
programs Minor editor demo cleanup 2015-07-20 18:39:10 -07:00
src Syntax nit 2015-07-20 18:55:09 -07:00
.gitignore Add gitignore 2015-05-18 22:17:36 -07:00
.travis.yml Add Travis build. 2015-07-09 13:48:14 -04:00
brick.cabal Add support for multi-line editors 2015-07-20 18:10:50 -07:00
cabal.config Add cabal.config 2015-07-11 16:01:41 -07:00
LICENSE Update LICENSE and package description 2015-07-07 21:01:23 -07:00
README.md Update README 2015-07-21 18:30:33 -07:00
Setup.hs Initial commit 2015-05-08 23:09:40 -07:00
TODO.txt Update TODO 2015-07-20 18:15:56 -07:00

brick

Build Status

brick is a terminal user interface programming library written in Haskell, 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.

The API exposed by brick is declarative. 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 -- even the bits that are stateful -- using a set of declarative combinators and it does the rest. All you have to do is provide functions to transform your own application state when input (or other kinds of) events arrive.

Under the hood, this library uses vty.

This library deprecates vty-ui. Some day brick, too, will have a 70-page manual.

Feature Overview

brick comes with a bunch of widget types to get you started:

  • 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
  • Extensible widget-building API

In addition, some of brick's more powerful features may not be obvious right away:

  • All widgets can be arranged in predictable layouts so you don't have to worry about terminal resizes.
  • Most widgets can be made scrollable for free.
  • Attribute management is flexible and attribute maps can be stored, loaded from disk, and customized at runtime.

Getting Started

The best way to get started is to build, run, and read the source for the various demonstration programs in the programs/ directory. This will help you get to know the library and what it can do. There is also extensive Haddock documentation.

$ cabal sandbox init
$ cabal install -j -f demos
$ .cabal-sandbox/bin/brick-???-demo

Status

brick is experimental. It does not yet support many of the features of, say, vty-ui. And there are some places were I have deliberately chosen to worry about performance later, for the sake of spending more time on the design. For a while my goal with brick will be to develop a very solid core library with minimal features. It should be possible to extend this library by making your own packages that depend on brick. If you do that, you'll also be helping me by testing whether the exported interface is usable!

There is a lot that I haven't documented in terms of design and intended API usage, but some of that can be gleaned from the demo program source and by looking at the implementation of the widgets that are already provided.

The development of this library has also revealed some bugs in vty, and I've tried to report those as I go. If they haven't been resolved, you'll see them arise when using brick.

Reporting bugs

Please file bug reports as GitHub issues. For best results:

  • Include the versions of relevant software packages: brick, ghc, and vty will be the most important ones. Even better, the output of cabal freeze would probably be helpful in making the problem reproducible.

  • Clearly describe the behavior you expected ...

  • ... and include a mininal 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.
  • If you make changes, try to make them consistent with the syntactic conventions I've used in the codebase.
  • Please provide Haddock documentation for any new functions you add.