Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Integrating FTXUI in an application with an existing logging system #947

Open
w8floosh opened this issue Oct 29, 2024 · 3 comments
Open

Comments

@w8floosh
Copy link

w8floosh commented Oct 29, 2024

Hello, I would like to know if it is possible to use this library with existing C++ applications that already use an own logging system. I am extending the functionalities of some SDK application which outputs lots of logs into stdout (and stderr sometimes). When I use these functionalities, I would like to use FTXUI to split the terminal in two sections, one just prints the logs generated by the application in the standard output/error and the other one prints some stats I choose.

Is it possible to "redirect" the existing application's standard output without modifying the way the application logs things and print it in that separate section of the terminal?

Thank you in advance.

@Epixu
Copy link
Contributor

Epixu commented Oct 30, 2024

I wanted to do something similar, see #778 so you know what kind of issues I encountered while doing so
I will start work on some optimizations that will hopefully make this feasible by december - it has been long overdue
There are probably alternative ways to display the log, but you shouldn't use paragraphs for it at this point

On the topic of redirection: I suspect it isn't possible to separate regular stdout from what FTXUI uses to draw, but if the logging system allows for attachment points it should be fine. Alternatively, there's probably a way to run the program as a child process with its own stdout handle, which you can then forward somehow to FTXUI in the main process.

@ArthurSonzogni
Copy link
Owner

  1. Call the wrapped app as a subprocess (example 1)
  2. Pipe the wrapped app (example 2)

In particular, in (example 2), you see stdin is redirected:

  // Save the original stdin:
  int original_stdin_file_descriptor = dup(fileno(stdin))
  
  // Change stdin to handle user input instead of the piped software:
  stdin = freopen("/dev/tty", "r", stdin);

  // TODO("Do something with `original_stdin_file_descriptor")

Does (1) or (2) fits your intents?

@w8floosh
Copy link
Author

w8floosh commented Nov 2, 2024

I think creating a subprocess (example 1) would better suit my case.
I have write access to the logging source code but it is a SDK code and it wouldn't make sense to touch it at all, because my feature is secondary and I don't want it to alter the original source code used in the whole application.
Furthermore, as the SDK I am working on is multithreaded, I may need to work with locks and race conditions on the stdout, as both FTXUI and the SDK print there.

I will try this sooner or later, as it is not a high priority work at the moment.

Thank you all for such valuable information 🙏🏻
Have a nice day

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants