ADR Suggestion: Use the web browser for documentation viewing instead of our documentation viewer widget.

[jamescrake-merani]

Current Implementation

The documentation viewer (DocViewWidget.py) is currently implemented using the QTWebEngine. While there is an implementation for documentation editing, from 6.0.0 this was disabled, and hasn't been enabled since. Current plans are to remove the documentation editing functionality from the application so that this window would just be for documentation viewing, and not editing.

These days, web browsers are well standardised. A web page rendered in one browser will most of the time look exactly the same in another browser. The only exception to this is where the user has an extension which customises the page. A popular example may be an extension which converts a page from light mode to dark mode. But if this is the case, I don't think its a bad thing that we respect the user's preferences of how they want to see the page. There is also a potential accessibility aspect to this as well, as a user may have their browser configured to display pages to meet a certain requirement, and we should of course respect this too.

The documentation viewer is the only dependency we currently have on the QTWebEngine. The Whats New Window uses QTextBrowser, which does not depend on QTWebEngine as it simply uses the subset of HTML implemented in QT for rich text rendering.

Benefits

• If we were able to remove our final dependency on QTWebEngine, we could be in a position to significantly reduce the distribution size of SasView.
• There would be a lot less code to maintain, meaning less places for bugs to creep in.
• The web browser is already an application the user is familiar with, and configured to their liking. It has a HTML rendering engine which is constantly being updated, and refined.
• The web browser already has the navigation features that a user might want; we wouldn't have to reinvent the wheel, and implement those in documentation viewer widget.

Offline documentation

Its important to note that using the web browser does not mean that we need to rely on online documentation only. We can still load local HTML files that are stored in the distribution.

Implementation details

On clicking the 'view documentation' button, the web browser is directed to the documentation. We firstly try to find a local version of that documentation page. If we can't find it on the user's system, we fall back to the online documentation for the specific version of SasView that the user is running.

The documentation would be opened in the operating system's default browser, which can be configured by the user.

Optional

We may want to allow the user to override the operating system's browser in the settings of SasView. I would be interested to hear other opinions on this.

[krzywon]

Discussion from the technical meeting:

• Able to remove the QTWebEngine and likely the sphinx dependencies
• Historically, we have flip-flopped between a sasview window and using the browser
• Users might have specific themes for their browser and/or OS, but that isn't applied to the Doc widget
• Not allowing user-based themes can break accessibility, e.g. forced font sizes, colors, contrasts, etc. all create barriers to accessibility

[backmari]

QtWebEngine is currently not available as a conda package, which prevents publishing SasView as a conda package:
conda-forge/pyside2-feedstock#167
It is available from PyPI in PySide6-Addons, so this is only an issue for the conda package, but thought I should mention it here. Note that PySide6 is an alias that installs both PySide6-Essentials and PySide6-AddOns.
cc @mrakitin