• Will be used to display what would be printed to the launcher console.
• Shamelessly copied from github.com/jpnurmi/ubuntu-desktop-installer.

It is the black component of the screenshot below:

FlutterWindow parent class has some business logic to perform on close (see the code snippet below). Calling DistroyWindow() is part of that. Doing as previously done (calling DestroyWindow() as part of the method channel handler) may skip part of that logic. That could be a cause for the access violation we noticed in the dumps if some other part of the framework attempts to dereference any of the structures cleaned up during the potentially skipped handler.

PostMessage, on the other, won't wait the message to be handled, thus the framework has the chance to do whatever it needs to. Posting a custom message allows the WndProc to call DestroyWindow, avoiding any possibility of ownership issues.

void Win32Window::Destroy() {
  OnDestroy();

  if (window_handle_) {
    DestroyWindow(window_handle_);
    window_handle_ = nullptr;
  }
  if (g_active_window_count == 0) {
    WindowClassRegistrar::GetInstance()->UnregisterWindowClass();
  }
}


LRESULT
Win32Window::MessageHandler(HWND hwnd,
                            UINT const message,
                            WPARAM const wparam,
                            LPARAM const lparam) noexcept {
  switch (message) {
    case WM_DESTROY:
      window_handle_ = nullptr;
      Destroy();
      if (quit_on_close_) {
        PostQuitMessage(0);
      }
      return 0;

...

This PR updates the slide show contents to match the output from the design team.

The window has been scaled a little bit and forced centering the user's main display as a partial workaround to ensure the OOBE will not catch user's attention before the right time. There is another side of this work on WSL launcher itself to find and control the visibility of the OOBE window as the main way of reaching this aim, so the window resizing and positioning is just a secondary measure.

Design screenshots and text can be found in the document: https://docs.google.com/document/d/16JdUzXox6bYDrsrrDvZ66LJskhy6qBxVyWBh2J7RobM/preview

This is how it looks now:

https://user-images.githubusercontent.com/11138291/161046142-b61c505d-6e65-449c-bfb1-822ffc8e6cdf.mp4

It turns out that due the simplicity of this app I could keep the state management in one single top-level widget. Thus no need for the provider package.

AppHome handles the InstallerStateController, making sure it's disposed in the end and reacts to its state change thru the method _buildStatusTile() which builds the pieces of the ListTile that are affected by the state changes.

I didn't make it stateless because I needed to ensure the controller's dispose() method is called. I could have wrapped it in a Provider, but that would be the single reason why I'd bring that dependency to this project. So, to my understanding that is the perfect use case for a stateful widget, even though I don't need to call setState()

By design this project is meant to display in the LogView widget the contents that would be printed in the launcher process stdout. That is achieved by having the launcher redirecting its output to a pipe whose read end is inherited as the stdin of this Flutter app.

When building the proof of concept I noticed a fairly consistent behavior of stdin.transform(systemEncoding.decoder) stream interpreting line breaks just after the first character. I did some investigation on the C++ side, but nothing was conclusive enough, so I preferred to perform this quick fix and investigate further later on, since I don't really have a clue about what causes that behavior at this point after the first investigation steps being done.

The fix implemented in the POC was just adding some more state to an already stateful widget. The need for state is what motivates writting a transformer class instead of just a function.

As demonstrated in the test file it is meant to be passed straight into stdin.transform().

void _transformerAssert(
    {required Iterable<String> input, required Iterable<String> output}) {
  final fakeStdin = StreamController<List<int>>();
  final stringStdin = Stream.fromIterable(input);
  fakeStdin.addStream(stringStdin.transform(systemEncoding.encoder));

  final resultStream = fakeStdin.stream.transform(StdinTransformer());

  expect(resultStream, emitsInOrder(output));
}

Back in the time we only supported Windows Desktop it was possible to rely on Microsoft Store to deliver a compatible VCLibs package to ensure the required runtime libraries would always be present in the target system.

We cannot rely on that mechanism on Windows Server. Thus we should avoid linking against them dynamically, since CMake 3.15 onwards offers way to do it statically.

The recipe can be applied to any recent Flutter app targeting Windows to avoid the need for shipping msvcp140.dll, vcruntime140.dll and vcruntime140_1.dll libraries. That can be handy for deployment under certain situations, but increases the overall app size since every native plugin (and the runner binary) will be affected by this option (a lot of binary code will be duplicated).

The size increase is irrelevant for the WSL case, because our main size constraint is orders of magnitude bigger than the Flutter-produced binaries.

Relevant documentation about this topic can be found in MS FAQ about Runtime libs, CMake CMP0091 policy and MSVC_RUNTIME_LIBRARY property

Notice the usage of generator expressions in the snippet "MultiThreaded$<$<CONFIG:Debug>:DebugDLL>" to ensure we still link against the debug runtime DLL's in debug builds, otherwise those builds would be much bigger and likely slower than they currently are.

A bare bones Flutter app on Windows is made of the flutter_windows.dll (provided by the framework) and the application runner executable compiled with Visual Studio build tools, with the build system (aka solutions and vcxproj files) generated by a set of CMakelists.txt files.

Program debug database is supplied for the dll, but not for the application runner. Enabling the build system to generate it requires one-line addition to enable it, per instructions found in this comment on Flutter repository.

The setup GUI is more verbose nowadays. Error messages are shown even when it heals itself. This regex change makes the splash react only to errors coming from the launcher.

Here is an example that would cause the InstallerStateController to react as if an irrecoverable error has happened. Notice that after a few SocketExceptions we finally get a connection. That's a normal behavior due the late server startup. The regex match is due "(OS Error: " part of the log.

2022-07-27 12:47:45.733412 INFO subiquity_server: Waiting server up to 30 seconds
2022-07-27 12:47:45.734439 ERROR subiquity_server: SocketException: Connection failed (OS Error: No such file or directory, errno = 2), address = /run/subiquity/socket, port = 0
2022-07-27 12:47:46.736066 ERROR subiquity_server: SocketException: Connection failed (OS Error: No such file or directory, errno = 2), address = /run/subiquity/socket, port = 0
2022-07-27 12:47:47.737158 ERROR subiquity_server: SocketException: Connection failed (OS Error: No such file or directory, errno = 2), address = /run/subiquity/socket, port = 0
2022-07-27 12:47:48.740348 INFO subiquity_client: Opening socket to Endpoint(/run/subiquity/socket )

https://github.com/ubuntu/WSL/issues/177 documents the possibility of dismissing the dialog that notifies the user when its time to leave the slide show and interact with the OOBE, halting the installation. Making the dialog non-dismissible gives time for the user to acknowledge the notification and automatically close out in case it doesn't react on time, moving the installation forward.

This closes https://github.com/ubuntu/WSL/issues/177 while we prepare the redesign that will remove the dialog in favor of something smoother.

Portugal variant requires more skilled translator. Brazilian one is being handled here, but the arb workflow wouldn't accept it without the more general pt version.

When attempted to package the Flutter build artifacts using Visual Studio, MSBuild failed to understand the '%20' in asset files names, added by Flutter because the original assets have spaces in their file names. Removing the spaces in the original files solve the issue.

Also, this fixes a typo causing a missing 'u' in the 'Ubuntu' name, as you may recall 😅

When the name fields contains special (i.e non-English) characters, clicking the continue button doesn't result in proceeding to the next step, despite the green mark suggesting the name is ok. Removing non-English characters from the name fixes this.

My computers that has nvidia gpu work well, but any computer has radeon graphic card, is screened by half triangle section color inversed.

When I close the window, I initialize with only root user.

Can I install ubuntu without splash?