Termbox is a library that provides minimalistic API which allows the programmer to write text-based user interfaces.

Maybe I simply don’t see it, but there is no function documentation in the C headers and hardly any comments in the source files.

The Python bindings are documented, though.

How come?

Hi,

I ran into some other problems, this time the wait_fill_event() function would hang on a keypress. Window resize worked fine. I traced the problem to fread() in termbox.c on line 428. It would always return 0 and control would jump back to while(1), going on forever. Turns out, some previous operation on *in descriptor had caused an EOF error and therefor all subsequent freads fail. Placing clearerr(in) before fread() solved the problem for me.

G.

Some people probably want to use CMake to include termbox in their project. Waf is also not used a lot throughout the C/C++ community, but I'm leaving that as is.

I'm not sure precisely what's going on, though I've managed to narrow it down to what I believe to be the smallest crashing piece of code (if it was real code I'd probably issue a close() at the end, but it never gets there anyway in this demonstration).

If I run the following script:

import termbox

tb = termbox.Termbox()

while True:
    tb.poll_event()

and then attempt to resize my terminal (both when resizing panes in tmux and resizing an xterm that it's running directly under), more often than not python will abort, simply dumping out this message:

python3.2: src/termbox.c:521: wait_fill_event: Assertion `r > 0' failed.

This also happens when using peek_event, and does not seem to be affected by the timeout passed to peek_event. It does not occur on key events, at least so far as I can tell.

As I said before, I'm really not sure what's going on here, and I don't imagine what I've got so far is all that helpful, so any advice on how to get a more useful crash dump would be much appreciated.

It triggers this assertion.

The program is:

#include "termbox.h"

int main(int argc, char **argv) {
    tb_init();
    tb_select_input_mode(TB_INPUT_MOUSE);

    struct tb_event ev;
    tb_poll_event(&ev);

    tb_shutdown();
    return 0;
}

See also: gchp/rustbox#32

Using Python to build a C library seems a bit... odd. Makefiles have been around for decades, and work perfectly for both small and large projects.

Makefiles have the advantage of being ubiquitous across UNIX-like systems. Anyone with a C compiler will have make, but a lot of people with C compilers won't have Python, and many of those won't want to install it just to build a single library.

Portability aside, Makefiles are a lot easier for contributors as well as for people who just want to use the library. Almost everyone who knows C can write, or at least understand, a Makefile, making it easier to contribute to projects that use them.

I removed the src and build directories because the root of the repo felt a bit empty with only src, README.rst and COPYING. It's easy enough to add them back in if necessary though, so let me know.

This also resolves issue #93, partly because I wanted to remove all Python code from the repo and partly because I couldn't be bothered to work out how the wrapper is generated and integrate that into the Makefile. Let me know if you'd prefer to keep it in and I'll see what I can do.

Using the same sequence of steps as keyboard.c, I get an assert in the very first block of reading code of wait_fill_event (currently line 581).

I'm using the latest 32-bit Cygwin on Win7/64. Since I'm using CMake I made a static library for termbox.c and utf8.c to live in.

I tried disabling the initial reading section of wait_fill_event, and that worked, until a resize occurred. Upon resizing the block of reading code in the while loop (currently line 613) would assert on errno==EAGAIN.

Using the termbox keyboard demo. The mouse events are reported as keyboard events, the reported key values appear to be random. Also, in xterm the box drawing characters are drawn as â.

Arch Linux, xterm 325, xfce4-terminal 0.6.3, termbox trunk, $TERM = xterm

Steps to reproduce:

1. From cygwin, ssh to a linux machine.
2. ./keyboard tb_init() failed with error code -1

Note in this scenario $TERM == "cygwin".

This is a bit semantic, but assuming the return value of tb_utf8_unicode_to_char is supposed to represent the length (as in strlen) of the resulting UTF-8 string out, a NUL code point should result in a 0-length string, not 1-length.

*** Error in `/home/lukas/Hacking/c/tinyrl/bin/tinyrl': munmap_chunk(): invalid pointer: 0x0000000000607f80 ***
^[[C======= Backtrace: =========
/usr/lib/libc.so.6(+0x732ae)[0x7ffff77a62ae]
/usr/lib/libc.so.6(+0x7872e)[0x7ffff77ab72e]
/home/lukas/Hacking/c/tinyrl/bin/tinyrl[0x402c88]
/home/lukas/Hacking/c/tinyrl/bin/tinyrl[0x4032f3]
/home/lukas/Hacking/c/tinyrl/bin/tinyrl[0x4021bc]
/usr/lib/libc.so.6(__libc_start_main+0xf0)[0x7ffff7753040]
/home/lukas/Hacking/c/tinyrl/bin/tinyrl[0x400e59]
======= Memory map: ========
00400000-00406000 r-xp 00000000 fe:03 3932165                            /home/lukas/Hacking/c/tinyrl/bin/tinyrl
00606000-00607000 rw-p 00006000 fe:03 3932165                            /home/lukas/Hacking/c/tinyrl/bin/tinyrl
00607000-00676000 rw-p 00000000 00:00 0                                  [heap]
7ffff751d000-7ffff7533000 r-xp 00000000 fe:04 13590                      /usr/lib/libgcc_s.so.1
7ffff7533000-7ffff7732000 ---p 00016000 fe:04 13590                      /usr/lib/libgcc_s.so.1
7ffff7732000-7ffff7733000 rw-p 00015000 fe:04 13590                      /usr/lib/libgcc_s.so.1
7ffff7733000-7ffff78cc000 r-xp 00000000 fe:04 13264                      /usr/lib/libc-2.20.so
7ffff78cc000-7ffff7acc000 ---p 00199000 fe:04 13264                      /usr/lib/libc-2.20.so
7ffff7acc000-7ffff7ad0000 r--p 00199000 fe:04 13264                      /usr/lib/libc-2.20.so
7ffff7ad0000-7ffff7ad2000 rw-p 0019d000 fe:04 13264                      /usr/lib/libc-2.20.so
7ffff7ad2000-7ffff7ad6000 rw-p 00000000 00:00 0 
7ffff7ad6000-7ffff7bd9000 r-xp 00000000 fe:04 13263                      /usr/lib/libm-2.20.so
7ffff7bd9000-7ffff7dd9000 ---p 00103000 fe:04 13263                      /usr/lib/libm-2.20.so
7ffff7dd9000-7ffff7dda000 r--p 00103000 fe:04 13263                      /usr/lib/libm-2.20.so
7ffff7dda000-7ffff7ddb000 rw-p 00104000 fe:04 13263                      /usr/lib/libm-2.20.so
7ffff7ddb000-7ffff7dfd000 r-xp 00000000 fe:04 13237                      /usr/lib/ld-2.20.so
7ffff7ff3000-7ffff7ff8000 rw-p 00000000 00:00 0 
7ffff7ff8000-7ffff7ffa000 r--p 00000000 00:00 0                          [vvar]
7ffff7ffa000-7ffff7ffc000 r-xp 00000000 00:00 0                          [vdso]
7ffff7ffc000-7ffff7ffd000 r--p 00021000 fe:04 13237                      /usr/lib/ld-2.20.so
7ffff7ffd000-7ffff7ffe000 rw-p 00022000 fe:04 13237                      /usr/lib/ld-2.20.so
7ffff7ffe000-7ffff7fff000 rw-p 00000000 00:00 0 
7ffffffde000-7ffffffff000 rw-p 00000000 00:00 0                          [stack]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

I recently experienced this strange error when my program quitted. It is related to tb_shutdown() as I found out by using valgrind: valgrind error. I don't have any idea how to fix this yet.

I'm not sure if this behavior of tb_peek_event() is intentional or not. I encountered it while attempting to make Tetris using termbox and trying to implement a time function and any inputs would stack rather than update on loop.

It can be replicated like this:

simply hold space and release when it shows 1.

#include <termbox.h> #include <thread> #include <chrono> int main(void) { int i; tb_init(); tb_cell c = {}; tb_event e = {}; while(i < 4) { tb_clear(); std::this_thread::sleep_for(std::chrono::milliseconds(2000)); tb_peek_event(&e, 0); if(e.key == TB_KEY_SPACE) { i++; } c.ch = 48 + i; tb_put_cell(0,0,&c); tb_present(); } tb_shutdown(); return(0); }

Feature request/idea: reading the front buffer

A function like tb_cell_buffer for the front buffer would be nice to have. I realize it comes with some amount of risk. If there is interest, I'd be happy to prototype something.

My use case is below, but I think this could be helpful in a more generic sense:

I've made a mini termbox based window manager of sorts and would like to implement some type of modal functionality. I'd like to be able to push the contents of the front buffer on a stack, show a modal, and then display the previous front buffer again after the modal is closed.

Since each section of my terminal is managed by an arbitrary number of window objects, it is impractical and inefficient to track their states manually.

Code contains #define TI_ALT_MAGIC 542, which is the alternative header for terminfo "extended storage format". This is ultimately used to correctly calculate the strings offset into the compiled terminfo database.

However, term(5) states that the alt magic is 0542, which is octal. TI_ALT_MAGIC should be set to (int)354, or prefixed with a zero.

I don't have any extended storage format terminfo files handy, but I am happy to test if you point me to where I can get some.

The README says "Termbox's interface only consists of 12 functions", which is not really accurate (there's 21 functions), and lists just the function names. I think it would be helpful to give argument names (e.g. tb_change_cell(x, y, ch, fg, bg) instead of just tb_change_cell()) and either list all 21 functions, or explicitly say that the listed functions are only the most commonly used ones, but the API has a some other functions too.

This adds a function to obtain file descriptors from termbox that can be be polled for IO-readiness. This can be used to integrate termbox into an event loop like asyncio or curio in python, or libuv in C, so the program can process other things (like network sockets) asynchronously with UI events.

The idea is to use tb_poll_fds() to get a set of descriptors, register them for polling (e.g. with EPOLLIN), and when any events arrive, the next tb_poll_event() can be expected to complete quickly.

(edit: markdown formatting and C usage example)