-
-
Notifications
You must be signed in to change notification settings - Fork 452
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 |
Actually i am using one screen and every time i switch the page context i am currently creating a new loop object with a reference to my screen object and the rendering component of the page. It works like that, but i still think removing the loop class would make accessing the rendering functionality much easier. The Loop Class is kind of an overhead i don't need and don't see the purpose of. Without it, i could just fetch the renderer when switching pages and the screen->runonce would update on its own. Current implementation: void TaskGui::Run() {
loop_->RunOnce();
}
Return<void> TaskGui::showPage(int id) {
auto r = pages_.getElement(id);
if (r.result != Constants::ReturnCodes::kSuccess) {
return Return<void>{
Constants::ReturnCodes::kFailure
};
} else {
page_ = id;
GuiPage* page = r.value;
auto renderer = page->getRenderer();
if (renderer.result != Constants::ReturnCodes::kSuccess) {
return Return<void>{ Constants::ReturnCodes::kFailure };
}
renderer_ = renderer.value;
loop_ = std::make_unique<ftxui::Loop>(&screen_, renderer_); // resets loop_ if it already exists
return Return<void>{
Constants::ReturnCodes::kSuccess
};
}
} Proposed implementation: void TaskGui::Run() {
screen_.RunOnce(renderer_);
}
Return<void> TaskGui::showPage(int id) {
auto r = pages_.getElement(id);
if (r.result != Constants::ReturnCodes::kSuccess) {
return Return<void>{
Constants::ReturnCodes::kFailure
};
} else {
page_ = id;
GuiPage* page = r.value;
auto renderer = page->getRenderer();
if (renderer.result != Constants::ReturnCodes::kSuccess) {
return Return<void>{ Constants::ReturnCodes::kFailure };
}
renderer_ = renderer.value;
return Return<void>{
Constants::ReturnCodes::kSuccess
};
}
} |
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: