Bachelor thesis: RAD tool for text user interface

View on GitHub



Bachelor thesis/project (Czech: Bakalářská práce)


RAD tool for text user interface


Petr Ospalý


Version: POC

Proof of Concept - early stage of development.

Quick Start


This is still VERY Work-In-Progress codebase and as of yet no practical application. This project is just capable of building and installing itself (build toolchain is almost worked out) and the created binary is just a (n)curses helloworld example for now.

If you are in a hurry or don’t want to read anything more:

  1. % git clone
  2. % cd baka
  3. % ./configure
  4. % make install

If you want to skip the configure part then at least check out the Makefile.config so you will not be surprised about installation destinations - by default these are used:

You can adjust the build process little more by using the configure script:

% ./configure --help

The script is without any arguments interactive and will ask a few questions - this is intended. I did not wish to hide anything from the user and with this approach I tried to eliminate any nasty surprises (overwritten files etc.). So by using the configure step the build will not silently use defaults - you must be explicit and set or sanction the values.

This project has very little requirements, so if your system has one of these compilers: cc, gcc or clang and it has installed ncurses package (library and its dev counterpart) then you should be fine.

Basically you need:

The configure script will test it for you.


Text user interface

Text User Interface (TUI) does not have a notion of pixel as that is the basic element in a graphical environment (GUI). Pixel’s role in the text based environment is taken by a character and the whole screen is formed by rows and columns of these characters.

There is a nice paragraph on wikipedia in the article about curses:

Curses-based programs often have a user interface that resembles a traditional graphical user interface, including ‘widgets’ such as text boxes and scrollable lists, rather than the command line interface (CLI) most commonly found on text-only devices. This can make them more user-friendly than a CLI-based program, while still being able to run on text-only devices. Curses-based software can also have a lighter resource footprint and operate on a wider range of systems (both in terms of hardware and software) than their GUI-based counterparts. This includes old pre-1990 machines along with modern embedded systems using text-only displays.


Baka is intended as a RAD (Rapid Application Development) tool(chain) for rapid development of applications in text based environments (here it means terminals). Very much in line with the pioneer of such tools - Borland Delphi - though my ambitions are much lower (and capabilities of text interface much lesser).

The fundamental component of a RAD tool is the Designer - where all the rapid development take the place (mostly). Without it the user (programmer) must learn API of whatever widget toolkit he chose to use. The purpose of any RAD tool and especially of the designer is to provide WYSIWYG features where the user intuitively design his application interface without any coding and all implementation details are hidden from him.

After the design time the user can hook up pieces of code on top of these widgets to give them some functionality. To achieve that: the RAD tool should provide a way of source code organization and automatic code creation - e.g. procedure/function templates (with auto-generated signature but empty body). We can call this the scaffolding.

Arguably the most popular way how to combine such scaffolding with the design element is by means of events (actions acted upon the widgets - mouse click, pressing the keys) and handlers (procedures/functions dealing with the events). Widgets have properties and handlers manipulate with the widgets through these properties. But only until they are invoked (triggered) by the relevant event, not sooner (usually).

Runtime and concurrency

So the last piece of this RAD system is a runtime. The runtime can be implemented as an event-loop or some concurrency system to provide the reactivity for the applications. If no such runtime would be present then the application would be strictly synchronous and appeared “frozen” most of the time. In a system without asynchronous runtime any invoked (triggered) handler would halt the rest of the application until it finishes its job and in the meantime no other event could be registered.

Try to think just a trivial scrolling feature - in a synchronous system (without any event-loop or concurrency) the scrolled portion of the application (text, form…) would not be scrolled in the “realtime” (real realtime systems are actually a whole another story…) - but instead it would have to wait until you finish the movement and release the scroll-bar. Only then a new event would be triggered to redraw the scrolled (and changed) portion of the application - as you can imagine that is very unfriendly user experience.


As was stated above - baka project tries to implement RAD tool for a text based interface - namely for the unix-like terminals with (n)curses support.

(n)curses (meaning: “New curses”) is the most popular “curses” compatible library (at least on Linux) providing a programming API and abstractions over the many terminal implementations.

It is (as of now) the only serious dependency which this project has…this may change with possible integration of Martin Sústrik’s libdill - the structured concurrency library. The same author also implemented golang-like concurrency in libmill.

Technical stack

This project uses the following products to be build and for function:

- Linux operating system
- GNU C compiler or clang
- C language + stdlib
- git
- ncurses
- shell + terminal
- (?) libdill

Project structure


- RAD Designer/IDE
- Basic widget set
- Source code manager (scaffolding)
- Runtime library (events handling)
- Build toolchain


- (n)curses
- libdill (?) (to replace my own event-loop implementation)

Why C?

The programming language of choice for this project is the C - (C99 to be exact).

Firstly ncurses and libdill are purely C libraries, so C language was a natural choice. Someone could argue that C++ would be a better fit (Object-Oriented language, hello…).

C++ also interfaces with C seamlessly and its compiler actually can compile C code without any hassle (many even prefer the c++ compiler for C projects).

So why not C++ then?:

So why C again?:

Why the name “baka”?

This project would not exist without (n)curses library, which is the successor of the original curses library - and the word “curses” can mean magic spells or insults in English. Also there is the Czech term “bakalářská práce” for the “bachelor thesis” (notice the baka in the beginning) and Czech is my native language.

When you combine these two things with my healthy interest in Japan then you get: baka a japanese “curse” meaning “fool” (used so often in the anime).

So putting it altogether: (n)curses means curses/insults, bakalářská práce has baka in it and that’s a popular japanese word for a curse - going full circle…

And last but not least…I am really terrible at making up names…