Implements the WinOobeStrategy

[CarlosNihelton]

Abstract

Complementary to #254 , this PR implements the component will feed the Application class with the behavior necessary to run the OOBE on Windows. No dependency on WSLg. Requires x64 platform.

Choosing the app strategy now depends on:

• the platform set by the compiler
• the definition of WIN_OOBE_ENABLED constant (not yet defined anywhere, thus this won't affect 22.04.1 release).

Since the top-level Application<> class remains the same both the supported command line and its semantics must be preserved.

Explanation

TUI

Terminal user interface support is still required because there are still situations only detectable during runtime that may prevent running the new OOBE, such as user disabling WSL2 localhost forwarding in ~\.wslconfig. Achieving TUI support is very similar to what is done in SplashEnabledStrategy, with the need to present the splash and close it when the TUI is ready for interaction. Thus, the InstallerController component is reused as is, even though it can only be used in TUI mode. In the near future we will be able to further reduce its functionality when we completely drop support for running the OOBE thrrough WSLg, but that's topic for another cycle, when we would be sure it won't be anymore necessary.

GUI

Command line

As with SplashEnabledStrategy, this component must offer the slide show (aka splash) and control the installer. As the OOBE on Windows is merged with the slide show as a single app, the installer is started at the do_run_splash() method. That means that the required command line must be known at that moment. makeCli() thus enables creating the command line for the OOBE by ensuring a minimal stem concatenated with further options passed as parameters. The command line for the setup may have an optional --prefil option, if the launcher succesfully acquire some user information necessary to prefill the UI fields during setup (user name and language). In such scenario we fill a file buffer with that information before starting the OOBE and write its contents into the rootfs after registration.

Setup versus Reconfiguration

do_run_splash() only runs for the WSL setup variant. The same application is also used for the reconfiguration variant. So, do_reconfigure() must be able to start the OOBE process as well, with different command line options. do_run_splash() and do_reconfigure() are never called in the same run of the launcher. In that situation, there is no need for the slide show, as the distro is already registered, but that's handled in the Flutter code.

The runtime requirements for both variants are the same but their behaviors are very different, so the function run_on_autodetect_ui() provides selecting which UI to run and accept callables with the different behaviors that must be achieved.

Setup UI can be selected via launcher command line (via the option --ui) as well as by setting the LAUNCHER_FORCE_MODE environment variable (reading it is part of the autodetection routine). For simplicity it was decided in the past that we wouldn't support the --ui option in reconfiguration, but instead rely on autodetection. That remains.

Server control and monitoring

In GUI mode everything server-related is done by Flutter. This is a great point of simplification, since we don't need to start it, spawn small processes to watch its startup and timeout after some attempts. Timeout heuristics are always questionable.

GUI Startup and IPC

The slide show reads text from standard input that comes from the launcher's stdout to monitor for errors, as before. Launcher is responsible for piping stdout to the child process stdin to make that possible. The same ConsoleService used inSplashEnabledStrategy fed by a named pipe is used for that.

Additionally, the launcher must notify the child process of the suitable moment to start the server (after registration is complete) and request it to gracefully quit, if TUI is required instead of GUI, for instance. Both behaviors are achieved by using distinct SetOnceNamedEvents created before running the OOBE and set when (and if) necessary. Closing the OOBE window is achieved by setting one named event (support for that is landing in canonical/ubuntu-desktop-installer#1032).

Trying out

Playing with this requires cloning https://github.com/canonical/ubuntu-desktop-installer somewhere, compiling the Windows entry point of the ubuntu_wsl_setup package, copying the generated artifacts into this repository build folder (x64\Debug for instance) and passing the WIN_OOEB_ENABLED definition during compilation. Quite complicated for now, but my next PRs will address that complexity by bringing UDI as a submodule and tweaking the build system to select and build the correct submodule automatically as well as defining the constant.

cd <this-repository-root-dir>
git clone https://github.com/canonical/ubuntu-desktop-installer UDI
cd UDI/packages/ubuntu_wsl_setup
flutter pub get
flutter build windows -t lib/main_win.dart --release
copy build/windows/runner/Release/* <this-repository-root-dir>/x64/Debug
cd <this-repository-root-dir>
.\DistroLauncher.sln

Set WIN_OOBE_ENABLED in the IDE GUI and debug it as you would.

[github-actions]

⚠️ Please check out carefully the isses found by clang-tidy in the new code ⚠️
⚠️ clang-format found formatting issues in the code submitted.:warning:
Make sure to run clang-format and update this pull request.
(1/1)

[EduardGomezEscandell]

Only comment is that there are a few places where you could use optional::operator-> instead of a reference. Not blocking because of this.

[CarlosNihelton]

Rebasing due merge conflicts.