read_stdin seems buggy and do some unespected things

[flagarde]

read_stdin seems buggy and do some unespected things

[flagarde]

@MCWertGaming Auto redrawing on resize windows can be integrated quite easily I think I made some PR already included to prepare the work. I agree some C++>11 are awesome. Maybe they could be integrated here with detection and option

[MCWertGaming]

Hey,
the enable_terminal was used to make it possible to use the terminal in raw mode without having to worry about input. Originally the input function @certik created had a fall-back implemented to make it possible to either enable the terminal processing and then read the input in real-time, or to disable it and read from the stdin as "pseudo input". Certik implemented it to test the multi-line prompt. I though about using it for things like:

A text editor that allows you to open a file and also act as cat-like too to read a file or output through the stdin. I have then later created a function that makes it possible to read the full stdin and get it as a full string in one go, but I haven't finished it yet. I also haven't looked into the strange thing that happen when the terminal is disabled. I'm also not sure yet what the the right purpose of this library is.

I guess that it would make sense to make a smaller call between us and @certik to discuss what we would like to implement as feature set and then also make a full proposal of a V1 "API" design. Like that we are making a functional design of the headers which represents all features we have discussed. We can then look into whether we would like to make a V2 design after that. But I guess that it would be important for this project to finally have a version that is convenient and makes sense to the user.

What do you think about this idea? I would also like to look into into two additional projects, which would be benefiting from this one, like a unit testing / integration testing framework for terminal based applications.

[flagarde]

@MCWertGaming Corect me if i'm wrong but the keyboard is sending to stdin by default. I understand it is nice to check if stdin is a tty or a file for example or if has been redirected but this can be check in any moment and it has not to be done in the constructor of terminal...

This is one of the change I think it would be nice to do to simplify the terminal class. Open by ourself the terminal and FILE* to console in windows and linux and put them in rawmode. and then if stdout/stdin has not been redirected to switch the stdin and stdout to this FILE* handles.

I had some problem in windows because is application mode GUI, windows doesn't create console by himselft so we have to do it by ourselft. If we do it in any case it would simplify and allow user to use stdin_console or stdout_console to be sure they are talking to a tty event if stdout our stdin has been redirected.

[flagarde]

@MCWertGaming Yes, I would aggree to have so discussion if you want. But I can't promess to work on the library (I'm doing it on free time and because this library is very useful and could be a nice replacement from other a bit more difficult to configure etc)

[MCWertGaming]

Hey, It's alright. I'm working on this in my free time as well and got busy for the last months with work etc. I'll try to get this into a V1 state in the next weeks so people can finally use this as a nice and uncomplicated curses alternative.

My requirements for this library have shifted a bit though in the last months though as well. Mostly because I'm doing responsive applications like games and animated UIs in the terminal, which is library is not that nice in. It also bothers me that I can't use C++20 features here like std::jthread to create a real time renderer etc. I guess that I'll look into bringing this to a well defined API and then make a derived library on top of that implements the real-time rendering and other things that come in handy. We can then look into moving stuff back into here or how we'll implement things. But I would like to keep this as compatible as possible in terms of compilers, systems and terminals.

I really appreciate your work on this library though @flagarde. You brought this a lot forward already. And I look forward to your next contributions!
Thank you.

[flagarde]

@MCWertGaming You can use c++20 of course but c++20 it's still not very standard in everyday life :( C++11 seems for now the best we can be assured on. Maybe you could develop c++ stuf that could be compiled in option.

Now i'm focusing on cleaning a bit more the code, allowing to attach the console on windows even on a GUI app, and finish the color setting for at least default terminal on the main OS + ansicon detection for old windows.

[flagarde]

@MCWertGaming The main feature I would like to be completed and I can contribute is the mouse handling and even more important the resizing capability (redrawing on terminal size)

[MCWertGaming]

@flagarde Yeah, C++11 is the right choice for this kind of library. I Just like to use newer C++ versions for my personal projects like my games etc. Mouse handling would be awesome, I'll implement the resizing in the separate terminal engine probably since it might be nice to have some kind of UI scaling / switching to another UI instead on my applications.

I'm currently creating an API design that should cover all features that are currently planed for V1.0.0 and will announce it when i'm done with it. I'd like you and a few others to review it so it's suitable for all use cases.