Views that are dynamically updated using asynchronous events that are
handled by urwid need to be redrawn.
Ensure that such events trigger a redraw.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
Wieh urwid > 2.1.2, the screen is only redrawn after urwid handles an
event (e.g., keypress, resize, ...) or an urwid alarm (it is like a
timer).
All other changes made to the UI do not trigger a screen redraw. We now
redraw the screen properly after moving from one screen to another.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
We recently made sure that after doing a snap refresh, the rich mode
(i.e., either rich or basic) is preserved. This was implemented by
storing the rich mode in a state file. When the client starts, it loads
the rich mode from said state file if it exists.
Unfortunately, on s390x, it causes installs to default to basic mode.
This happens because on this architecture, a subiquity install consists
of:
* a first client (over serial) showing the SSH password
* a second client (logging over SSH) actually going through the
installation UI.
Since the first client uses a serial connection, the state file is
created with rich-mode set to basic. Upon connecting using SSH, the
state file is read and the rich-mode is set to basic as well.
Fixed by storing the rich-mode in two separate files, one for clients
over serial and one for other clients.
LP: #2036096
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
create_task has the following note:
Important: Save a reference to the result of this function, to avoid a
task disappearing mid-execution.
Convert existing usage of create_task to run_bg_task, if that
create_task is not actually storing the result.
I implemented these a long time ago to help working on parts of the ui
by allowing a way to script moving past some screens. I haven't used
them in ages, it's pretty bad code and probably a fragmentary answers
file is a better solution to the same problem. What do you think?
We used to rely on the narrow non-breakable space to be displayed as a
star in basic mode. This is not great and could impact other screens.
We now make use of two check-marks (each replaced by a star in basic
mode) and mask one of them in rich mode using display attributes.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
In addition to verified publishers being indicated by a check-mark, we
now have starred publishers indicated with a circled star.
If unicode support is not available, for instance with serial
connections, we use a different number of stars to represent:
* verified publishers: 2 stars
* starred publishers: 1 star
* others: no star
Because our mechanism to substitute unicode characters with ascii
equivalents expect a 1:1 mapping, we cannot simply replace the circled
start by two stars. To workaround the issue, we added a narrow
non-breakable space.
When support of unicode is available, this character shows up as a
normal space.
When support of unicode is not available, it gets replaced by a star.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
The following commit added an unconditional return statement in the try
block of _move_screen, effectively making the associated else block
unreachable.
a7bcc7fa add a way to wait for something with notification after 0.1s
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
The make_ui() function / coroutine returns a BaseView (i.e., a
screen to display to the user).
That being said, when the application calls, make_ui(), it does not come
with a guarantee that the view returned will be displayed to the user
immediately.
One of the reason is that there are multiple await statements before the
we call the ui.set_body function. Therefore, tasks running concurrently
cannot reliably expect that they execute after the display is refreshed.
Perhaps more importantly, when the make_ui() function takes more than .1
second to execute, we display a "Progress" screen that stays visible for
at least one second. This can effectively delay a lot the moment when
the view returned by make_ui() is shown to the user. A lot can happen in
the meantime.
As the result, the view returned by make_ui can be outdated by the time
we show it on the screen.
One way to work around this problem is to store in the controller a
reference to the view that it returns in make_ui(). This way, the
controller can modify the view and keep it up-to-date until it gets
shown to the user.
Unfortunately, some controllers (e.g., the storage controller) do not
modify / mutate the existing view object when a modification is needed ;
but instead instantiate a new view object.
This patch introduces a level of indirection that can be used by these
controllers. Instead of returning a view object from make_ui(), the
controllers are now allowed to return a callback ; which in turn will
return a view object.
https://bugs.launchpad.net/subiquity/+bug/1968161
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
* locale - let it check interactive-sections again
* Turn Serial into a whole new screen
When in serial, first offer the rich/basic choice (or SSH button),
and only show the current welcome screen if we choose rich mode.
Add a back button on Welcome if we are on serial.
LP: #1919251
This fixes a problem where you drop to a shell and refresh subiquity
from that shell -- the client tries to restart but it is running in the
background and so crashes trying to modify the terminal settings. So
this kills the subprocess before restarting. This required the extremely
angry PR I sent before: forcefully killing the subprocess also crashes
the client before restart in a similar way.
Here is something you can try with a live server installer today: drop
into a subshell and type "kill -9 $$". The installer will crash with an
'Input/output error' from tcsetattr.
What's going on is some deep unix arcana: when the subshell exits via
signal somehow the shell's process group is still in the foreground
(even though there are no processes in it?) and calling tcsetattr() from
a background process is not allowed. So the fix for this is reasonably
simple (or at least: short): call tcsetpgrp() to put our process group
back into the foreground. A background process doing this gets sent
SIGTTOU, but if we ignore that, all is well.
Frankly this is all very strange and I would like a lie down now.
the point of this is to have the event loop running while loading
autoinstall commands, which means we do not have to start and stop the
event loop inside load_autoinstall_config if there are early-commands to
run.
Olivier Gayot