-
Notifications
You must be signed in to change notification settings - Fork 672
Migrate UI to textual #3997
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
base: master
Are you sure you want to change the base?
Migrate UI to textual #3997
Conversation
…nto migrate-textual
|
Looks cool @svartkanin :D Tested a little bit, I came across was f1 help screen crashed and user setup screen was missing The rest seems like it's already fully functional (considering what you said about the flicker), like how you can use cursor, very bamby friendly 🖱️ Would be cool to add globally visible hints for Then more specific go in help screen ? |
|
Thanks @h8d13 for testing!
|
|
Most submenus (The ones with a |
|
Yeah I thought it would be a good thing if it also worked in these menus reduce keys needed to get around Had another question, I saw that runners were going to be more restrictive (and paid) for github and always thought the ISO one takes a while (seems unnecessary for smaller changes) . Is there anyway we can disable it unless on major releases/needed ? |
|
I like this, and I think there's only one thing that we might need to address first (and then I'll leave some general things i noticed while trying that we don't need to fix now) Issue
For later
There's also a small anomaly that I don't think is related to this PR at all, but I'm noting it down because it kept happening:
|
| self._update_selection() | ||
|
|
||
| def update_selection(self) -> None: | ||
| def action_focus_left(self) -> None: |
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.
I wonder if here, we can somehow use .notify() and perhaps hide the Toast with CSS? As espeakup appears to read those texts.
If you don't have a more clever solution to making espeakup understand the menu changes ofc.
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.
Not sure I'm following on this one, which toast are you referring to?
I'll have a look at this one.
this was a deliberate decision as the textual examples themselves came with this behavior and IMHO it does make some sense
But I understand that it's deviating from the current behavior and if we think it will cause too much friction I can add that back in.
Good catch, I'll have a look at it. |
We can deviate from the current, it's one more button to press but it makes it more explicit, as I wasn't always convinced that I selected anything in the old menu so.. this might actually be a good thing hehe. |
Ah, the color is official but the terminal in the ISO doesn't render it correctly (it doesn't map the escape codes perfectly to the CSS I think). |
This may be fixed with #4031 |
Hmm not sure I fully grasped this one, so when I do
and then
It should be correct no? What do you mean with
|
|
Okay I had a bold assumption that accessibility would be available considering the maturity of the framework, but it seems I was wrong Textualize/textual#2425 Maybe I can hack around it by setting the hardware cursor... |
I guess that works fine, as I don't know why I was expecting to be able to un-select an option and "leave it blank for now" (aka, un-do my choice): |
Oh damn, I actually also just assumed it would be there 😅 |
|
Just an idea for the actual installation screen: Is there any way we could display "major steps" What I mean is that they see all the process which is great but have a kind of "Summary" steps: Perhaps like in bottom right "Formatting disks (1/14)". |
|
That's something for the future and unrelated to this PR |




This PR migrates all menus to the
textualframework introduced with #3879.The current implementation is creating a new textual app and destroying it with every menu/submenu which is not how it is supposed to be.
The final version will use a single app instance and switch between screens smoothly but to keep things (somewhat) manageable, that change will be done in a follow-up PR in which the code will be moved to an async model (see the wifi screen that is already doing that https://github.com/svartkanin/archinstall/blob/fdb002fa31471d86e1d5e99bc6ec4c21ba1a3b15/archinstall/lib/network/wifi_handler.py?plain=1#L1)
I have tested everything somewhat but not extensively yet. I have opened the PR regardles for now in case someone wants to have a go at it and provide some feedback.
[X] Test everything thoroughly