kazdragon / terminalpp Goto Github PK

This means that it is not possible to copy from one canvas to another.

It should also have a const conversion operator to element const &.

Before diving in and creating components, it would be worthwhile to begin documenting the object model and the things required from it, including how they could be developed programmatically, and how they could be instantiated from some kind of DSL.

Some work was done on a precursor effort in https://code.google.com/p/paradice9/wiki/MuninComponents and https://code.google.com/p/paradice9/wiki/ComponentThemes and there was some pratical work and write up on the DSL in KazDragon/paradice9#145 .

As a user, I wish to maintain an inspectable grid of arbitrary elements.

Currently, if the cursor was hidden in a previous process, then the cursor can never be shown (because TT++ always thinks it is). It should instead start off in an unknown/optional state.

This will enable a user to check whether a particular modifier is set.

is_printable and glyph::operator<< should be exported

In csi.hpp, osc.hpp etc. There are plenty of things not added.

NOTE: This may result in code entries being converted to char[], since there are quite a few multiple-character entries.

Allow conversion using a std::string an an attribute to apply to all elements.

e.g. terminalpp::string(stdstr, attr);

Currently requires an explicit low_colour initialization.

For anyone to be able to use Terminal++, it requires at least some simple documentation in the Readme.

Some command sequences (such as some extended character sets and some DEC Private Set commands) have an extra character before the arguments (e.g. "\x1B[?6n" for Device Status Report).

The characters that are valid for this seem to be ? and >.

An object that is capable of viewing into a smaller part of a main canvas, or even another canvas view.

While tinkering with Paradice, I changed the borders of a tabbed frame to use the unicode box drawing characters. This worked for about three lines before reverting to gibberish.

It would be nice to know why.

https://en.wikipedia.org/wiki/Box-drawing_character

Need extra constants for mouse reporting.

At the moment, if you want to place a single element on the terminal, it is necessary to write something along the lines of:

terminal.write(""_ets + elem);

It should be possible just to write the element itself.

The terminal object should be capable of changing output depending on the known behaviour of the actual terminal, and performing every-day operations such as cursor management and writing strings. This should obsolete the current ANSI-functions API.

Due to a bug, CppUnit renders Clang's memory sanitizer useless. It would be useful to keep the option open.

On GCC, building a static library with hidden symbols and linking it into a shared library causes link time errors.

For example, shift-right-arrow transmits an extra "1;2" as arguments. This is currently not captured in the virtual keys for these events.

Up/Down/Left/Right, etc., can be transmitted with repeat counts. At the moment, this is fixed to 1.

Create a header that automatically includes the most common header files.

At the moment, it is required that a canvas is built outside of the screen, then copied into the screen in order to be drawn.

By allowing screen::draw to take a canvas parameter (and only storing one canvas internally, which represents the last frame drawn), this means that the canvas does not need to be copied an extra time. It also has a side-effect that screen does not have to be re-created whenever the canvas size changes.

Currently, we support interpreting mouse inputs, but this will never happen since no command to enable the mouse mode is ever output.

Currently, the mouse parses with (x,y) co-ordinates being offset by 32. This is correct as far as the parsing goes. However, Terminal++ works with a 0-based system and ANSI works with 1-based, so it needs another 1 subtracted to convert it to the local co-ordinate system.

At the moment, it would be necessary to look into the token received for the vk, determine that it's a control sequence, and then look at that sequence's meta property.

That's a little too much work for a simple modifier.

Most of the things that are in the old string tests can be copied over.

To prove that Telnet++ actually works as described in practice as well as theory, actually integrate it into an application.

Otherwise it could clash with another project's "doc" target.

It is possible to set the window title of the remote client. A command should be added to enable this.

In encoder.cpp:encode_character_set_ext, the char array is not NUL-terminated. This results in an OOB access when using strlen() in lookup_charset.

Ctrl-Enter is received (correctly) as vk 138, so the command version is being received correctly. Just the return keystroke itself is incorrectly parsed.

Currently, tests print elements as "glyph[], attr[]" due to incomplete debug text. Naturally, this is pretty awful when it comes to comparing two results.

If a character would be written in a different character, but it's actually the same character (e.g. 'X' is both US_ASCII and UK), then don't bother changing the character sets.

Allow terminal.read(string) to parse a stream of text into text, commands, mouse events, and so on.

This will enable code equivalent to "element foo('x')", which currently would go through two implicit constructors (for glyph, then for element).

\x should set the state back to idle, but stays in escaped.