neonrust / termic Goto Github PK

Is this terminal-dependent?
If so, I guess we'll need to clear the front-buffer upon a resize event (forcing a complete redraw of the screen)... and -> :(

For example calling print() with a negative X.
That is, the text starts off-screen (to the left), but may eventually flow onto the screen.
Not really a critical feature, though :)

i.e. center- or right-aligned text; a new print overload that, given an alignment and an "anchor", prints the specified text:
screen.print(alignment, { anchor_x, y }, text, fg, bg, style)
Which means that if alignment is "center" the anchor_x value will be the text's center. Analogously, with "right" alignment it will be the last cell of the text. Might have an optional max_width argument as well.

This probably also implies there will be some text-width API.

screen.text_width("asdf") // returns 4

To be able to control colors and style int the "string" content itself. Putting 'string' in quotes because the type might not be a string in the final implementation.

Essentially, just what escape sequences does for normal terminal output. However, we need full control over what is written to the terminal.

Might add support for "theme", so the style syntax may have color names and such baked in.

Example (completely fictional): \a|title|This is the \a+|red|title\a- text
Where title is a color/style name (fg, bg and style is controlled by the theme)
\a+ pushes a new style, and \a- pops it back to the previous style.

The advantage to this is terser user code. Also things like alignment combined with styling becomes much easier, which currently needs to be done manually (a measure() + multiple print()s).

e.g.:

mwe: -1
mwe: -9  SHIFT
mwe: -33  CTRL
mwe: -39  SHIFT+CTRL
mwe: -49  ALT+CTRL
mwe: -55  SHIFT+ALT+CTRL

Those values should always be -1 or 1.

So the user code registers its function to draw the screen. It may also be changed at any time, or possibly even connect multiple functions to the signal (if implemented as a signal, of course).

This is, for example, would simplify for timer callbacks that modify the screen (or modifies that that indirectly rely on that the screen will be redrawn afterwards).

It actually seems that the terminal emits escape sequences with only button 0 (for all buttons).
I'm quite sure this worked before.... :(
Buttons 0, 1 and 2 works as expected.

Currently, the screen is only redrawn when an event happens. This is either input or resize.
We most likely also want periodic updates. Enter timer events! ;)

"termic" isn't bad, being similar to "thermic", implying "hotness" :) But it is a tad long, since it is used as name space.
Maybe even something that doesn't contain "term" ? ;)

Wrapping a string long text\nwith\nmultiple\nlines to max 8 characters, will wrap it to too few lines.

Actually, currently, an assert will fail, which is caused by the same ignorance of whitespace. :(

While resizing the window (narrower), garbage may remain in the left edge of the screen.

Could this be caused by the signal (interrupt) while rendering? Although, I shouldn't think so; the SIGWINCH signal handler only sets a flag, which is handled on the next loop..

Described here:
https://gist.github.com/christianparpart/d8a62cc1ab659194337d73e399004036

Currently, there's only a single timer (or zero), that when set emits the on_timer signal.

Would be nice if there could be any number of timers, similar to how setTimeout() and setInterval() in javascript works (yeah, I know, i threw up a bit in my mouth).

That is, setting the timeout/interval, it returns a handle that can be used to cancel the timer.
It is technically not difficult.

One question though; how does the current timer fit into this?

Which will/might allow for some tricky rendering, where each layer may interact with each other (or not).

For example, compose the screen of two layers:

• layer 0: normal printed text on the screen
• layer 1: a "background" rendering that uses sub-cell resolution (using block characters), however not in cells where layer 0 contains text where it instead uses sub-cell averaging (since the effective resolution will be 1/4, i.e. a normal cell).

Admittedly, the usefulness of this is quite limited. ;)

Currently the code to read input uses a mix of std::iostream and file descriptors.
This is bad of course.

Likely, using only file descriptors is the better choice, as waiting for I/O and such doesn't really exist in the C++ stdlib.

This has a few benefits:

• All print() overloads don't need three arguments for this, just one.
• Theming becomes more flexible (general theme support is also a TODO).

Currently, some shortcuts have been made that assume a char-width of 1.
Must properly handle wide-characters.

This also implies correct handling of UTF-8 characters.

e.g. the text and utf-8 helper functions.