[Devlog #002] Introducing TMUI

I am wrapping up the revision for Ave's terminal UI code, from which a single-header library, TMUI (Terminal Mode User Interface... because TMUX is taken), is being formed. Initially, whenever I needed to render to the terminal, I would make a number of ncurses calls and move on. I would compress them into functions, but they weren't straightforward to reuse for new UI components. For example, to enable the user to type into a text field, I would call FillEntry(...):

The entry parameter simply stores a ncurses WINDOW and some properties about the window (e.g. width, height, hot, cold, etc.). Whichever char is "typed into the entry" will be stored in buf, and then I call UpdateEntry(...) to reflect that on le screen:

So these two defunct functions would for example power the text fields present on the now-familiar login screen:

They're defunct because they weren't useful when considering entries that strongly deviated from the traditional entry like large text boxes or search fields. The edge cases would make the tangled mess I wanted to avoid through compression in the first place. I decided properly defining data types for each UI component and some related functions would be fine, even if some repetition were to occur. Then have the main code use this API without considering ncurses at all, and avoid the need to compress any of its routines. They follow a naming convention similar to ncurses, however, so it's not too unfamiliar. Below is the addch and delch tmui versions for the new txt_field_t types:

[Note: Funny how properly deleting a character is a little involved. We shouldn't dismiss the simple as trivial.]

These handle private text fields, a title, the offset when characters go over the width, and the style of the text field (curly braces, regular braces, parentheses, etc.). The text field itself now holds the contents typed in so far. There are other functions like txt_field_set_hot (whether to highlight it or not), txt_field_update (which replaced the generic FillEntry), etc. And there are similar functions for text boxes, buttons, labels, email items, etc... except when they're not similar. Then they have their own unique routines, and I call those instead :)

Of course, if these UI components ever proliferate, a less repetitive strategy would be wiser.

All of what you see are their own set of UI components now, with a proper barrier between my code and ncurses! One can introduce the notion of backends, and switch between an ncurses implementation of tmui with some future one. Of course, this isn't anything terribly new or exciting in the world of software development. However, now I may trivially add terminal theming using tmui, after which I complete Ave Terminal 1.0, and give my full attention to the graphical mode user interface (GMUI? No?).

Until November's monthly update. We'll see if I get to stream too (probably not due to Handmade Con!). Previous stream may be found here

Do you intend to release Ave for windows ?
In the screenshot, you seem to spend a lot of screen space on borders, and as a result it only shows 5 e-mails. Is it close to the final "design" or will it be more compact ?

Terminal Ave is for Linux, but it might work with Windows Bash. Graphical Ave will have Windows support.

mrmixer You seem to spend a lot of screen space on borders, and as a result it only shows 5 e-mails.

Yeah there are two things I could do: (1) Move the e-mail items further up while compressing the space between each and (2) Allow more if the user grows the terminal window. I'll take these into consideration, so long as they don't hamper the simple visuals.