Further Webassembly Enhancements

We have ported our QT MDI desktop/mobile accounting application to the browser thank to Qt Webassembly.

It is still a Technical preview, but results are very interesting especially for.

• No installation needed (automatic update included)
• Ability to open a template when starting the program.

The wasm application provides many of the functionalities of the desktop application, but some are still lacking.  

Here you can start the application in the browser here: https://www.banana.ch/it/startbanana

I do compliment the QT team. What you have achieved with webassembly is great!

Our team has started working with QT the webassembly when it was presented some years ago and we have invested quit a lot of time. Our team has also created a version of our application for Android and iOS. This was of great help for creating the wasm version. Still, porting the Qt desktop application to webassembly it is challeging and requires a lot of learning. Ideally a desktop application should be compiled unmodified to webassembly, but this is not possible. To achieve such parity, we think that the Qt libraries should be improved. Based on our experience we provide some feedbacks and suggestions hoping that can be of some help for the Qt dev teams.

The topic is quite complex and I’m sorry but the information is limited to the essential and it is intended for people that know about this topic better than I do. I will eventually update and provide further information in the future.

Documentation improvements

The documentation for webassembly is very limited and mostly is related to setting up the environment.

More information is needed, especially in relation to installation, compile of qt source, use of asyncify and also about debugging.

Asyncify

QT Webassembly applications cannot call the .exec() function for showing dialogs. Instead it should use the .open() and async. This is a major limitation and one of the major issues when porting desktop application to web assembly.

In our code base and in QT (like QMessageBox::question ) there are still code that use the .exec() for dialogs.
Some code has been changed to not use .exec(), but in many part of the program there are still lot of code that follows the .exec() call and require a full refactoring.
The asyincify only allow to call .excec() once, but in the software there are still quite a lot of code that call .exec() multiple times. This code need also a full refactoring.

The process of converting the application without the .exec() is quite challenging and time intensive. Ideally webassembly application should support .exec() as under desktop application.

There is the option of using the QT_EMSCRIPTEN_ASYNCIFY =1, but it is not easy.
Related to this point we suggest:

• Improve the documentation for use of
  Currently the necessary information is only available on forum or support.
• The precompiled webassembly are not compiled with asyncify. For easier start, we suggest making available also a precompiled webassembly with asyncify.

Also related to the .excec() we think it is necessary to:

• Clarify what is the future of Qt related to the use of .exec() code.
  The QDialog::exec() documentation already states “Note: Avoid using this function; instead, use open().”. A mention that this function should be avoided when using webassembly.
• exec() function is quite convenient for many cases.
  Using the .open() require to use lambda functions and the capture variable [].
  This may be in some case quite challenging. The documentation should explain how the captured objects should be created and how will they be destroyed in relation to connected event. For variable that are usually created on the stack, should we use the std::shared_pointer or the internal qt object deletion model.
  A “Best practice” guide on the topic of memory management for QT and the relation with event and asynch programming and also how to combine with std:: pointers is much needed.
• Clarify if you are you planning to support multiple .exec() or only one in webassembly?
• In case .exec() is not fully supported on webassembly, it should be mentioned in the documentation.

Other necessities

Many other desktop software are experimenting with webassembly, one of the recent example the libreoffice project port to webassembly.  

https://www.theregister.com/2022/02/19/webassembly_port_libreoffice/

https://fosdem.org/2022/schedule/event/lotech_lowa/attachments/slides/5218/export/events/attachments/lotech_lowa/slides/5218/fosdem_2022_wasm.pdf
They have an interesting list of “More problems to tackle”.

For many parts is the same for us. Here is a list of desiderata from the developer point of view.

• Access to local files and File System Access API (https://bugreports.qt.io/browse/QTBUG-99611)
• Persistent storage for user settings and files
  Like desktop and mobile applications also wasm applications should have a way to easily save setting and have access to a directory for user ”/AppData/”
• Close events.
  Currently if the browser or the tab is closed, user data is lost.
  How should we handle it on webassembly?
  Events that allow to save the status and the data when the browser or tab is closed and retrieve the status and data when the application is restarted.
• Support for Accessibility standards.

Looking more forward:

• Port to a WASI.
  Ability to use webassembly application out of the browser.
• Using webassembly modules (libraries) within a QT application. Easy call of external libraries, passing parameters, setting permissions.