Keep Qt WebEngine out of the build environment for the upcoming 34.0.0 release

[i2h3]

Goal

Stop pulling Qt WebEngine into the build environment when building the Nextcloud Desktop Client, while keeping pre-34.0.0 branches buildable from the same blueprint.

Context

nextcloud/desktop#10092 removes the QtWebEngine dependency from the desktop client entirely — source code, CMake, and platform packaging. The change targets release 34.0.0 on master.

The client never shipped a feature that strictly required an embedded Chromium. The only use was the legacy embedded login flow (Flow v1 / WebViewFlow), gated behind a server capability and already superseded by the system-browser-based OAuth flow (Flow2) for every Nextcloud server ≥ 16.0.0. With the legacy flow removed, the dependency has no remaining purpose.

Benefits of removing QtWebEngine from the build environment

• Smaller distributables. QtWebEngineCore alone is hundreds of MB. Dropping it shrinks the installer and the disk footprint of every install.
• Faster Craft builds. Qt6WebEngine is one of the most expensive Craft packages to fetch and (when self-built) compile. Removing it from the runtime deps cuts macOS build time and bandwidth meaningfully on every clean build.
• Smaller attack surface. Chromium has a high CVE rate. Even when unused at runtime, shipping it forces the project onto Chromium's upgrade treadmill.
• Simpler signing on macOS. The dedicated QtWebEngineProcess.app helper inside QtWebEngineCore.framework no longer needs separate codesigning treatment (removed in the desktop PR).
• Fewer ARM caveats. Qt5/Qt6 WebEngine availability has historically been spotty on ARM Linux; the project no longer needs optionals (!isARM) branches in the Nix flake.

Why we can't simply delete the blueprint's WebEngine code

This blueprint serves whichever ref of nextcloud/desktop Craft is pointed at. We still need to build pre-34.0.0 branches (33.x, 32.x, …) for backports and patch releases. Those refs still:

• declare BUILD_WITH_WEBENGINE as a CMake option (default ON);
• call find_package(Qt6WebEngineCore REQUIRED) (REQUIRED on Linux/Windows);
• link Qt::WebEngineCore / Qt::WebEngineWidgets into nextcloudCore.

If we strip the option, the conditional qtwebengine runtime dep, and the -DBUILD_WITH_WEBENGINE flag from the blueprint, pre-34.0.0 builds will fail at the find_package step on every non-Apple platform.

Proposed change

Keep the option, the conditional dependency, and the -D flag — but flip the default in nextcloud-client/nextcloud-client.py:

-self.options.dynamic.registerOption("buildWithWebEngine", True)
+self.options.dynamic.registerOption("buildWithWebEngine", False)

Then:

• Building 34.0.0+ master (default args): option = False → qtwebengine not installed; -DBUILD_WITH_WEBENGINE=OFF passed (34.0.0's CMake silently ignores the now-unknown variable). ✅ Goal met.
• Building 33.x or earlier with --options nextcloud-client.buildWithWebEngine=True: option = True → qtwebengine installed; -DBUILD_WITH_WEBENGINE=ON passed → pre-34.0.0 CMake honors it. ✅ Backports keep working.

CI / release pipelines that build 33.x tags need a one-line addition to pass buildWithWebEngine=True to Craft.

Merge order

This change must land after nextcloud/desktop#10092 reaches master. Flipping the default to False while desktop master is still pre-34.0.0 would break master CI: find_package(Qt6WebEngineCore REQUIRED) would fail on Linux/Windows.

Future cleanup

Once 33.x reaches end-of-life, this blueprint can drop the option, the conditional dep, and the -D flag entirely.

[i2h3]

According to @mgallien, we can check for the client version to build in the blueprint script and include QtWebEngine depending on that.