qt6: Merge latest develop

[Martin-Nyaga]

This PR merges latest develop into qt6, including porting all the necessary parts of the additional code.

[DSCaskey]

I reviewed the code and ran some tests of the Windows build. It runs, but has issues that need fixing. The 1st issue that needs resolving is the xerces lib is not deployed with the Windows build.

Even though the unit tests are failing (in the variables translations), I would just assume merging this PR as it would be easier for me to make fixes once it's merged and on the FashionFreedom repo.

That being said I would like to get input from @csett86 as to the macOS build. I should note that the ci does produce a warning in regards to the MacOS build that we probably want to resolve.

[csett86]

Before checking: Where did you already test the resulting builds, @Martin-Nyaga? Windows? Linux? Mac? If so, which versions?

[Martin-Nyaga]

@csett86 I tested this on Windows 11, Qt 6.5.3. Apart from the OS/Hardware, my Qt environment matches this gist from the recent PR by @xypp3 exactly. I don't readily have access to a MacOS or Linux environment at the moment, but I could arrange to run some quick tests on Linux at least within a couple of days.

@DSCaskey I'll take a look at the xerces deployment, it should be as simple as manually copying the .dll using copyToDestdir similar to openssl, right?

Just to give some additional context, this commit contains the only direct changes that I introduced to successfuly build and run. The rest of the changelog is direclty from develop.

[csett86]

Here my macOS results, macOS 12.7.5:

Seamly2D is not usable.

It launches, but prompts with the following.

Menus are not opening, and then crashing with https://gist.github.com/csett86/b4ac606f31202a82b77b6afcc6dd7bd0 after a short while.

[csett86]

Now retested on macOS Sonoma 14.5, here at least the menus work, but opening a file did not. It got stuck after selecting the file, this is the spindump: https://gist.github.com/csett86/1090bec8c2c80adcd11465f8d14b2f13

So as a summary, not a usable program on macOS at the moment, still needs quite some work

[Martin-Nyaga]

Hi @csett86! As I said before, I unfortunately don't have access to a mac environment at the moment, so I can only provide some ideas/possible explanations as to what is going on.

Layer backing

Starting with the error about Layer backing - it looks like we explicitly set QT_MAC_WANTS_LAYER to 1 in main.cpp, which while I can't verify, seems quite likely to be the source of the error.

I understand this might be necessary on some MacOS versions, and otherwise doesn't hurt on other versions where layer backing is the default (as desrcribed in the error message). Perhaps we should simply silence this error as we have done with others in noisyFailureMessageHandler?

Skipping QEventPoint

All the information I can find on this error points to this: https://bugreports.qt.io/browse/QTBUG-103935

It appears that newer MacOs versions raise this error in Qt 6 when using the laptop touchpad, which sends touch events in addition to the regular mouse events. If acceptable, we can consider disabling touch events altogether on the MainWindow instance:

    // Disable touch events on MacOS 12+ which lead to spurious warnings
    window.setAttribute(Qt::WA_AcceptTouchEvents, false);

I don't know if these caused the crash that you got on macOS 12.7.5, but it's possible.

MacOS 14 - Frozen after opening a file

Based on the trace, I think a possible explanation is a locked settings file. Qt is not able to acquire a lock for the file, or more likely believes the file is already locked (i.e. there is an existing .lock file), and so cannot reliably read it.

I've once come across this on Windows, where I had a .lock file left over after exiting the application. It's unclear why this happens, as the .lock files should get deleted. Perhaps it happens if the application crashes or is closed unexpectedly for some other reason, and there wasn't an opportunity to clean up the lock file?

However, you can easily check if this is the problem by checking for a .lock file alongside the standard settings file with the app closed.