-
-
Notifications
You must be signed in to change notification settings - Fork 443
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
Make ScreenInteractive methods public #945
Comments
Hello! Would the FTXUI/examples/component/custom_loop.cpp Lines 47 to 51 in 55af678
See doc: You directly have access to: Loop::RunOnce();
Loop::RunOnceBlocking(); This way, you can control when "processing" FTXUI happen, and when to wait. |
Hey Arthur, thanks for you quick reply! First of all yes, i could make it work with your loop class, but currently i am doing a multi page application which uses a collection of layout containers each making a single page. If I would use your loop class i would need one loop per page, which doesn't make much sense in my opinion as all the loop does is making sure you call preMain and postMain. The class doesn't add more functionality and i would love to remove the need for extra loop objects so i thought it may be easier to open these methods up fo r public access. In the end you could still use the loop class with that change! Maybe i am missing something here, but i still think that this would be better. |
Do you mean you are using nested screen? One screen loop looping into another screen loop? Maybe you can use a single loop and switch pages with dynamically or with |
I would like to include ftxui into a realtime scheduling framework where there are tasks from which you derive so that you get the rt functionality without much work.
For that it would be pretty nice to be able to skip the usage of the screens loop functionality and just call the RunOnce, ... methods directly by the scheduling defined in the framework.
I think my request could be done by just making these methods inside the class public:
I think this change would actually be great for other scenarios as well, not only when you need tight control over resources but also when you just want to have a little more control over the ui rendering in general.
I don't think this change would affect the current usage of ftxui too much.
The text was updated successfully, but these errors were encountered: