-
Notifications
You must be signed in to change notification settings - Fork 10
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
feat: add abstract app module and refactor config #206
base: main
Are you sure you want to change the base?
feat: add abstract app module and refactor config #206
Conversation
Works on all three UIs offers a generic function to ask a question that platform independent. If the user fails to offer a response, the installer will terminate. In the GUI this still works, however it may not be desirable to prompt the user for each question. So long as we don't attempt to access the variable before the user has had a chance to put in their preferences it will not prompt them Changed the GUI to gray out the other widgets if the product is not selected. start_ensure_config is called AFTER product is set, if it's called before it attempts to figure out which platform it's on, prompting the user with an additional dialog (not ideal, but acceptable)
8042817
to
82d0c94
Compare
ou_dedetai/tui_app.py
Outdated
|
||
def get_version(self, dialog): | ||
self.product_e.wait() | ||
question = f"Which version of {config.FLPRODUCT} should the script install?" # noqa: E501 | ||
question = f"Which version of {self.conf.faithlife_product} should the script install?" # noqa: E501 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To my knowledge, I need to wait on self.product_e.wait() as if not, the TUI charges through the installer process; should this way now be handled by the TUI's implementation of app._hook_product_update()?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Surprisingly enough it didn't charge through - it waited for the question to be answered before going to the next screen probably because we have two main threads in the TUI:
- The input processing thread (main, don't block me)
- When events are triggered they're spawned on a new thread (this is the installation thread). Since the ask call is blocking, this gets stopped while the user is inputting their value (which the processing is done on the first thread)
Then if you notice in TUI's ask implementation there is an event wait to communicate between the two threads
Comments on DemonstrationThanks for this! The framework you have here looks great. The TUI is a Frankenstein of my own thought, so anything that simplifies it and makes it less bloated is great—I do like seeing lines of code removed. As mentioned to Nate, I see tui_screen.py as a library that could feasibly be used outside of our project, so also the same with certain aspects of the display code in tui_app.py, say lines 1–350. LogosLinuxInstaller/ou_dedetai/tui_app.py Lines 1 to 350 in 0def2e5
(Given the hope of simplifying our queue/event code, many of these lines could be squashed/removed.) The task processor code in tui_app and in gui_app could also be brought into the abstract class. I would also hope that the choice_processor code in tui_app.py might find its way there. @n8marti has handled the GUI, so I will leave that to him. (Given your review, you might be the third person we've needed: someone who understands both the TUI and the GUI, haha.) I originally tried to code for the various UIs particularly in msg.py. This eventually got away from me and found its way back in msg.status(). There's likely a fair chunk of room for messaging to be brought into the abstract class given how much code is relatively unused in that module and how msg.status is accounting for each UI. The abstract class lets us do that without all the if/elif. General CommentsI had also tried this in installer, but the GUI needed enough odds and ends to be separated at the time. Now that we have our working base, I think it'd be great to try to reel in the various odd bits and make these more united, all in the spirit of #147. As mentioned elsewhere, this would also be helpful for #2 and #87, and for drastically improving code reusability/maintenance. Given your further comments about the suggested config changes, that would go well with #187. While I think all these issues are too much for one PR, I do think we could lump #147 and #187 into this PR's scope as a way of refactoring our code. Thinking Out LoudThis framework might enable me to further simplify the various calls within tui_app to tui_screen. tui_curses and tui_dialog are fairly static at this point. There are some parts of tui_screen that need to be abstracted, particularly in the console_screen. I've also considered changing the tui_screen class to utilize a method of the tui_app that flags the need for tui_app.refresh to be run again. |
Am I understanding correctly that in the GUI the user will see the "Choose which FaithLife product" window first, then they will see the GUI installer window, with all the options pre-populated with defaults? So then they can make adjustments, or just click "Install"? |
Not quite, I liked the current GUI flow so much I didn't want to modify it. Before and after this PR it behaves the same, however if someday in the future there was a code path that tried to retrieve the faithlife product before the prompt showed up, it would open a separate dialog asking that question. In the GUI's case we probably want to avoid this, however the code will handle that case and avoid an error if such a code path were to exist in the future. |
Okay, I'm happy with that. |
If you @ctrlaltf24 can take care of the potential merge conflicts, then I'll look it over again for approval. |
Expanding usage of this framework.... |
and migrate APPDIR_BINDIR and WINESERVER_EXE
removed RECOMMENDED_WINE64_APPIMAGE_BRANCH as it wasn't used RECOMMENDED_WINE64_APPIMAGE_FILENAME as it was only used as an intermediate to get the version, not use storing in it's own right. combined SELECTED_APPIMAGE_FILENAME (stored) amd APPIMAGE_FILE_PATH (was only in-memory before)
variable did nothing, replaced with a string
automatically invalidate network cache after it expires keep in mind this doesn't run enforce_icu_date_files on update
and starting to migrate from msg to the abstract class
removed curses.KEY_RESIZE, there wasn't a RESIZE at refactor time start using app.status rather than msg.status
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Additional changes needed:
- reload config
- store network cache in a separate file (in local state)
Additional work:
|
Works on all three UIs offers a generic function to ask a question that platform independent. If the user fails to offer a response, the installer will terminate.
In the GUI this still works, however it may not be desirable to prompt the user for each question. So long as we don't attempt to access the variable before the user has had a chance to put in their preferences it will not prompt them Changed the GUI to gray out the other widgets if the product is not selected. start_ensure_config is called AFTER product is set, if it's called before it attempts to figure out which platform it's on, prompting the user with an additional dialog (not ideal, but acceptable)
Screenshots
GUI Sample
TUI Sample
CLI Sample
GUI behavior
Before Product is selected
After product is selected
This is meant as a demonstration, we should expand the scope if we decide to go this direction
Fixes: #147