An issue in Preview

[KevinH]

The reversion of that commit is exactly what I was waiting for. So it looks like Qt 6.92 is out of the question, but that change may make it into Qt 6.9.3.

So if we decide to build our own Qt 6.9.2, we will need to revert that same commit.
I will see if I can find that commit in patch form so we can add it to our set of patches.

It probably won't hurt to add their other patch as well.

Update:

Here is the first patch to fix a new bug Arch included (see 9dd5105.diff.zip attachment).

And then the patch we need to reverse is also attached (see ddcd304.diff.zip)

[DiapDealer]

I'm only currently custom-building QtWebEngine for the AppImage (enabling proprietary codecs). The rest of the Qt6 dependencies are being installed from official Qt binaries (via aqtinstall). Patching other Qt modules could change the AppImage build process considerably. If Qt6.9 doesn't provide something Sigil can't do without, I might prefer waiting for a version that doesn't require patching the base module.

[RbnJrg]

Originally Posted by KevinH

The reversion of that commit is exactly what I was waiting for. So it looks like Qt 6.92 is out of the question, but that change may make it into Qt 6.9.3.

It seems that after Qt 6.9.2 the next version will be Qt 6.10.0.

[DNSB]

Originally Posted by RbnJrg

It seems that after Qt 6.9.2 the next version will be Qt 6.10.0.

As near as I can tell, the final release date for 6.9.3 is 2025-Sep-25 and for 6.10.0 is 2025-Sep-23. Considering that several of the phases for 6.10.0 have already slipped, I would be very surprised if 6.10.0 met it's release data.

[KevinH]

DiapDealer,
I think both patches are to qtwebengine. I am sure the reversal one was there and the other patch is optional.

I will try both tomorrow.

[KevinH]

Originally Posted by DNSB

As near as I can tell, the final release date for 6.9.3 is 2025-Sep-25 and for 6.10.0 is 2025-Sep-23. Considering that several of the phases for 6.10.0 have already slipped, I would be very surprised if 6.10.0 met it's release data.

We never do Qt 6.x.0 as these 0 releases are always full of bugs. That is the bleeding tip of the Qt dev tree. We will move next to Qt6.9.2 (with patches) or wait for Qt 6.9.3 and after that move to 6.10.2 or higher.

There are just too many bugs in the early releases to spend time on.

[DNSB]

Originally Posted by KevinH

We never do Qt 6.x.0 as these 0 releases are always full of bugs. That is the bleeding tip of the Qt dev tree. We will move next to Qt6.9.2 (with patches) or wait for Qt 6.9.3 and after that move to 6.10.2 or higher.

There are just too many bugs in the early releases to spend time on.

Sadly all too true. Much like I tend to wait for at least the first point release of a Linux distribution before giving it space in my VM collection, waiting for the first major update to a Windows release before installing, etc. I do make exceptions for rolling releases since there I know I'm going to be spending time on the bleeding edge.

[philja]

Over the years, I note that Qt is frequently at the root cause of so many problems in Sigil. Is Qt indispensable or is there a more stable alternative?

[DiapDealer]

There is no alternative without a complete rewrite.

[DiapDealer]

Originally Posted by KevinH

DiapDealer,
I think both patches are to qtwebengine. I am sure the reversal one was there and the other patch is optional.

I will try both tomorrow.

Ah... That would be great! I saw 'core' in the path and just assumed. It makes sense that it would be WebEngine considering the bug reports.

[DiapDealer]

Does this have any relevance to Windows?

[KevinH]

I am not sure. It may if a recent Windows uses the most recent Mesa library internally. It was the update to the Mesa library which triggered the need for the reversal.

But if I had to guess it would be Linux Vulkan users it impacts and some wayland users. Not Windows or Mac but who knows if QtWebEngine uses Mesa internally?

[DiapDealer]

I'm including the software Mesa implementation Qt has made available for years for Windows in the Sigil bundle.

https://download.qt.io/development_r...mpipe/windows/

It hasn't changed in a long time. So I doubt Windows would be affected. I asked mainly because I had already built 6.9.2 for Windows. And as always with new Qt versions, it takes longer to build and results in a larger package. The full build took over 9 hours this time (6-core athlon with 32gb ram). QtWebEngine was about 7 hours on its own! I just wanted to avoid a WebEngine rebuild if possible.

The minimum Windows SDK requirement to build QtWebEngine with MSVC 2022 went up with 6.9 as well.

[KevinH]

Wow, something is strange. I can build all of Qt (including QtWebEngine) on my Mac Studio arm64 machine with 32gb ram in just about 1 hour. My older MacOS intel box i7 with 32gb of ram takes 3 hours to do the same thing. Is the Windows compiler that slow or is the build not parallelized?

[DiapDealer]

Originally Posted by KevinH

Wow, something is strange. I can build all of Qt (including QtWebEngine) on my Mac Studio arm64 machine with 32gb ram in just about 1 hour. My older MacOS intel box i7 with 32gb of ram takes 3 hours to do the same thing. Is the Windows compiler that slow or is the build not parallelized?

QtWebEngine has always been a mess of a build on Windows. Very memory intensive. A myriad of tiny build tools and libraries that are already available on Linux and Macs need to be compiled first. The list of pre-requisites for building are also ridiculous. Plus there's a massive linking phase at the end of the process where things slow to a complete crawl (even when limiting parallel jobs to avoid maxing out memory usage). Things actually managed to get inexplicably worse when MSVC became fully 64-bit (the tool chain for building 64-bit binaries was actually 32-bit for years).

It's possible that things might work better on Intel, but I don't have the time (or the money) to build a new Windows machine that will literally sit collecting dust between custom Qt builds. Building Qt for Sigil is the only thing I need a physical Windows machine for these days. If not for QtWebEngine's incompatibility, I could probably do better cross-compiling for Windows with MinGW on Linux.