Read Me

Widget library is a small library for writing simple console user interfaces
using "high level" widget like interfaces. It has been designed to be simple to
use, extend, understand and integrate. It has also been designed to be 
completely abstract and therefore doesn't do any input or output by itself 
directly. Instead all input is passed into the library using virtual key semantics
and all output from the library is passed back to the application inside an 
abstract "frame buffer" object.
This means that host application will be responsible for using whatever means 
it wants for mapping user input to the virtual keys understood by the library. 
Also in order to display any data the host application will be responsible 
for transferring (printing) the output form the library
to the actual terminal screen buffer for display using whatever means it wants.
While this may sound like a burden and something that makes the library cumbersome to use
the reality is actually quite the opposite. This design makes the library
very portable, testable and flexible. Say you want double buffering for instance, 
easy to do. Or you want to script your widgets? Well thats easy to do too!
Ideally there exists another library that provides a uniform interface to a bunch
of terminals (and terminal like environments) for a multitude of platforms.
Unix, Linux, Windows etc. With this library one could access the terminal contents,
manipulate the cursor and use fancy techniques such as colors and other video
properties. However this library is not that library, since this is just a widget library.

Someone might also ask why the library doesn't provide a "main" loop. In my opinion
most applications have such a wide variety of needs about what they want to do in their 
main loop, that it simply is the best and most correct solution to leave it up the client.
Any non-trivial application might want to for example, wait for user input,
wait on any other objects such as sockets, pipes, file handles or do polling or any
other kind activity in the application loop. Massaging all this information and context
into any "generic" library defined main loop becomes tricky really quickly. Not to mention
a case where one wants to use combine several libraries each having their own perverted
notion of what a "main loop" should look like. 

In my opinion in any application/library design the library should just provide the tools 
for doing stuff and the application should provide the context; the glue for putting things together
and managing the activities between different components. 
Anyway, enough with the jabbering and on with the real stuff...

The library depends only on the standard C++ environment and the awesome boost 
C++ package (no one should code c++ without boost!).
It was developed against boost 1.33.1 but porting to newer versions should
be straight forward.

The library was originally developed as a subproject of a bigger project.
Thats why it has crappy naming and stuff. This should be easy to fix though 
should there ever be need for that.

For more information see the sample code.

The library is distributed under the MIT license.

The current build system uses Boost.build and Jamfiles
are provided. However migrating the code over to any other build
system should be trivial.

The library is not all perfect and not fully optimized. There's plenty of
needless drawing going on. However so far this hasnt been a major issue,
but at some point if you're working with a terminal with slow IO system
this might become essential. Also im not sure if the current way of doing 
"drawing" is good, or whether it should be changed for message based/queued notifications. 
Regardless if you have comments/suggestions/fixes please dont hesitate to 
send them to me if you want.

You can submit these either to sourceforge message board or the directly to me
via email. 
Sourceforge: http://sourceforge.net/projects/theveryuncool/
Email: ensi@ensisoft.com

Current features:

ASCII support only
Animation support
- scrolling text support
Policy based design
Input policies
- alphanumeric input
- numeric input
- password input
Tab completion policies
- filebrowser tab completion policy (should actually live outside the lib's scope)
- basic tablist
Widget/window events
- focus
- draw
- cursor
- keydown
- select
- click
- easy to add more events as needed
Color support
Video properties support
- reverse video
- underline
List/table selection modes
- single select
- multi select
Menus