cpp-terminal road map

[MCWertGaming]

I have thought of some things, I would like to to do with cpp-terminal to make it better for it's purpose - providing a way to write cross-platform terminal applications. I thought of doing those steps in the particular order:

1. Split cpp-terminal into smaller use case defined parts (use sourcefile instead of 'just' headers #67)

• cpp-terminal/base.hpp which provides the raw functions to handle console input (basically the color functions and such)
• cpp-terminal/window.hpp which provides a manages "window", basically the window class
• cpp-terminal/input.hpp which provides the input functions
• cpp-terminal/prompt.hpp which provides the prompt and things like (Split the prompt into its own header file #72)
• cpp-terminal/tools.hpp wich provides all function which are just meant for being used inside of the library
• restructure the header files (restructure the header files #117)

2. Improve testing and similar

• Add testing of multiple compilers #148
• Improve stand-alone test (if needed) (improve standalone test #109)
• add github-action for checking if clang-format was applied (checking of clang-format for pull-requests #92)
  -> add github actions for automatically applying clang-format (like with /bot apply-clang-format as issue comment)
• add testing for the interactive prompt (CI: add tests for an interactive prompt #59)
• enable more warnings and make them errors (CI: Enable all warnings on all compilers and turn them into errors #33)
• add static analysis like clang-tidy / cpptest / other solutions (if possible) #149
• use the doctest.h to a cmake or git sub module (Unit testing #88)
• introduce actual unit testing to prevent breaking things by accident #150
• automatically copy colors.cpp from the examples for stand-alone test #151

3. Improve the libraries core

• merge window and window_24bit together (merge window and window_24bit together #96)
• change the stand-alone color functions to always use the best, but supported color range
  -> fixes The color chart in ./colors seems incorrect on macOS #108
• change the window class to always chose the highest (but supported) color range
  -> fixes menu_window_24bit does not seem to work on macOS #107
• add functions to determine ANSI code support by the current terminal (Functions for determining terminal support #102)
• make the window class specific functions also available as stand alone
  -> maybe even use those functions inside of the Window class to prevent duplicate code
• fix the visual studio color problem (Visual studio code terminal issue #95)
• Improve the window class render() algorithm (Implement more efficient render algorithm #71)
• implement all TODO's #152
• fix ALT+N (fix ALT+N #118)
• change default arguments like unicode to be automatically #153
• let cpp-terminal handle most things it self small imprevements #120

4. Finishing up

• create an actual documentation for cpp-terminal (Create a wiki #70)
• document taken keys (document taken keys #112)
• add more exceptions to help developers on finding mistakes (adding more exeptions #98)
• add proper versioning (Release tags #90)
• improve the readme (Improve the readme #75)
• Document all tested terminals (Document all terminals that we tested #73)
• maybe remove get_term_size_slow() (removed the get_term_size_slow() function #115)
• add copyright notices to all files #154

5. Extending the library

• add more options for drawing
• integrate proper resize handling into the window class (Resize #94)
• optimize the Window class for real time applications (games mostly)
• make windows inside of windows possible #156
• add syntax highlighting
• add argument handling and processing #155
• make the prompt more customizable for other developers
• support Dear ImGUI add support for Dear ImGUI #121

I will make this Issue pinned on the repository and update it when needed to keep track on the things we want to do. Also for other peoples and possible contributors. Help is always appreciated!

[MCWertGaming]

Do you think is good? @certik I thought this is a good idea to keep on track on things. You can do some things as well if something interests you.

[certik]

I think this works! (I would call the header files *.h, but that's minor.)

We plan to sync with the latest cpp-terminal in LFortran:

https://gitlab.com/lfortran/lfortran/-/issues/292

and maintain the multi-line REPL capability on all platforms. So we will ensure things keep working.

I have other ideas that I would like to do and use cpp-terminal for:

https://gitlab.com/lfortran/lfortran/-/issues/293

[MCWertGaming]

The thing with the files: The change is not important for the library. I'm just seeing that most "modern" c++ libraries use .hpp instead of .h to match the source files .cpp. I think it would look more modern, also it would be always clear that this is a c++ library not a C one.

To the other changes: Feel free to add things or ask me to add some. I don't think that we need everything for a full featured text editor, but you could add that as optional feature for the window class.

[MCWertGaming]

Also great that you want to sync cpp-terminal. It make the merge of new features easier next time.

[MCWertGaming]

I have looked at what you are planing to do. I think that would be an awesome project. I would add some C++ goodies too like clang-format, clang-tidy, cpptest etc.
Also we can make it with true color support when we have done the automatic conversion of true color to 8bit / 4bit colors. We wouldn't have to care about different terminal support anymore then. I have some projects too:

Snek - a small snake clone with some extra gamemodes:
https://github.com/BlackVyperStudios/snek
(branch menu, master is the old ncurses variant)

Also this project is not intended to be well coded. I'm working on this with a friend who is really new to programming and don't want to make it too complicated

Snek ultimate - the same but by myself with some more features in mind, like multiplayer and a particle system to make nice looking visual effects:

https://github.com/MCWertGaming/snek-utimate

This is not really started yet, because i have done other things. but this will be the next thing i want to do.

Also I started a chess library with currently all required movement checking. Not yet done and also not yet playable as I don't created a front end yet. I'm planing on doing one for the terminal and one as actual GUI version

https://github.com/MCWertGaming/chess/tree/main/chess

I have also some other ideas for terminal games, but these are the ones i want to get working on in the future.

[MCWertGaming]

I have created multiple files now and moved all functions. My goal would be to also move most functions out of the BaseTerminal() and Terminal() classes into the base.h so users will have functions like get_term_size() without requiring the input.h file. Also I would suggest to do something with the Terminal and BaseTerminal classes. What is the constructor of the BaseTerminal class doing? @certik

#ifdef _WIN32
    explicit BaseTerminal(bool enable_keyboard = false,
                          bool /*disable_ctrl_c*/ = true)
        : keyboard_enabled{enable_keyboard} {
        // Uncomment this to silently disable raw mode for non-tty
        // if (keyboard_enabled) keyboard_enabled = is_stdin_a_tty();
        out_console = is_stdout_a_tty();
        if (out_console) {
            hout = GetStdHandle(STD_OUTPUT_HANDLE);
            out_code_page = GetConsoleOutputCP();
            SetConsoleOutputCP(65001);
            if (hout == INVALID_HANDLE_VALUE) {
                throw std::runtime_error(
                    "GetStdHandle(STD_OUTPUT_HANDLE) failed");
            }
            if (!GetConsoleMode(hout, &dwOriginalOutMode)) {
                throw std::runtime_error("GetConsoleMode() failed");
            }
            DWORD flags = dwOriginalOutMode;
            flags |= ENABLE_VIRTUAL_TERMINAL_PROCESSING;
            flags |= DISABLE_NEWLINE_AUTO_RETURN;
            if (!SetConsoleMode(hout, flags)) {
                throw std::runtime_error("SetConsoleMode() failed");
            }
        }

        if (keyboard_enabled) {
            hin = GetStdHandle(STD_INPUT_HANDLE);
            in_code_page = GetConsoleCP();
            SetConsoleCP(65001);
            if (hin == INVALID_HANDLE_VALUE) {
                throw std::runtime_error(
                    "GetStdHandle(STD_INPUT_HANDLE) failed");
            }
            if (!GetConsoleMode(hin, &dwOriginalInMode)) {
                throw std::runtime_error("GetConsoleMode() failed");
            }
            DWORD flags = dwOriginalInMode;
            flags |= ENABLE_VIRTUAL_TERMINAL_INPUT;
            flags &= ~(ENABLE_LINE_INPUT | ENABLE_ECHO_INPUT);
            if (!SetConsoleMode(hin, flags)) {
                throw std::runtime_error("SetConsoleMode() failed");
            }
        }
#else
    explicit BaseTerminal(bool enable_keyboard = false,
                          bool disable_ctrl_c = true)
        : keyboard_enabled{enable_keyboard} {
        // Uncomment this to silently disable raw mode for non-tty
        // if (keyboard_enabled) keyboard_enabled = is_stdin_a_tty();
        if (keyboard_enabled) {
            if (tcgetattr(STDIN_FILENO, &orig_termios) == -1) {
                throw std::runtime_error("tcgetattr() failed");
            }

            // Put terminal in raw mode
            struct termios raw = orig_termios;
            raw.c_iflag &= ~(BRKINT | ICRNL | INPCK | ISTRIP | IXON);
            // This disables output post-processing, requiring explicit \r\n. We
            // keep it enabled, so that in C++, one can still just use std::endl
            // for EOL instead of "\r\n".
            // raw.c_oflag &= ~(OPOST);
            raw.c_cflag |= (CS8);
            raw.c_lflag &= ~(ECHO | ICANON | IEXTEN);
            if (disable_ctrl_c) {
                raw.c_lflag &= ~(ISIG);
            }
            raw.c_cc[VMIN] = 0;
            raw.c_cc[VTIME] = 0;

            if (tcsetattr(STDIN_FILENO, TCSAFLUSH, &raw) == -1) {
                throw std::runtime_error("tcsetattr() failed");
            }
        }
#endif
    }

This in detail. If it does both preparing the terminal and preparing the input, we should probably consider to either split it into two classes /just make functions out of it. Or we have to include the input into the base.h or something like that. I basically want that the header files make sense in terms of what's in there.

[certik]

Yes, it prepares the input as well as output, depending on the platform.

I am fine with hpp too, as well as rearranging things.

You can suggest what you think should be done and we can discuss.

[MCWertGaming]

Sure, i'm going to create a WIP pull-request as soon as the biggest things are done!

But I have yet another question. What does this do? Removing it changes nothing for me on linux and it's excluded for windows:

#undef B0
#undef B50
#undef B75
#undef B110
#undef B134
#undef B150
#undef B200
#undef B300
#undef B600
#undef B1200
#undef B1800
#undef B2400
#undef B4800
#undef B9600
#undef B19200
#undef B28800
#undef B38400
#undef B57600
#undef B115200

[certik]

This was introduced in #36. You can read the discussion and the issue (#35) it closed over there.

[certik]

Once we move to cpp, we will remove this from the header files, so there won't be an issue anymore.

[MCWertGaming]

Okay, great. Thank you!

[MCWertGaming]

Moved the roadmap to https://github.com/jupyter-xeus/cpp-terminal/projects/1