Sigil on Apple M1 running under Rosetta 2?

[KevinH]

Wow! Great work! Thanks for the links to the patches. We will work on creating our own Qt 5.15.x tree and hosting it.

[democrite]

Great. That will be helpful. Maybe there are various other patches floating around such as backports of 6.x fixes that we may find someday.

Only issue I've noticed, I believe you can guess, dark mode behavior is different in 5.15.x, at least in somethings. I do not know of all the developments, fixes, new bugs, etc. since. I found mention of the bug and your use of Kovid's workaround. I'm not sure how it's related. On 5.15.2, on startup in dark mode, text is black in some controls such as context menus, and some dialogs. Attached is how one dialog appears.

Toggling system dark mode after Sigil startup seems to fix it. It's also possible macOS dark mode support has improved. Trying "macos" instead of Fusion style, so far from a few minutes of use, seems ok. I have a build of that and will try it for a while. Such I imagine you'll notice whenever you have a chance to get to 5.15.2 support.

[KevinH]

It may be arm64 or Monterey related. We do not use Fusion style on macOS. We use mac style. We are the only platform that does that.

[democrite]

Could be arm64 or I think maybe the newer Qt. The current Intel build looks ok. A minor detail for the moment. Maybe you'll notice it when you get around to using 5.15.2, or you may later decide to release macOS builds with Qt6 as the support is supposed to be much better. Whenever such a time comes is fine.

[KevinH]

FYI, I have updated my laptop to XCode12.1 (my laptop is running Catalina (10.15)), updated to cmake 3.22.1 and installed ninja and I am now trying a Qt 6.2.2 build natively. If that works, I will try an arm64 cross compile build. Work on porting Sigil master to Qt6 is underway and I need a Qt6 build to test for macOS specific issues. Once I get those ironed out hopefully that will give you extra Qt options for Apple M1 boxes.

[democrite]

Sounds great. I will likely try Qt6 whenever that is ready. Various things like a more native look like Big Sur style dialog boxes will be nice.

Was thinking. As SF symbols has been out for a while, I’m not sure if it contains enough icons for a native looking icon set on supported systems. I sort of recall at least one site offering a larger set of sf symbol like icons. Could be a bit of a effort but maybe someday. May help with eventually getting a very native look.

[KevinH]

In case it helps ...

My own Sigil repo:

https://github.com/kevinhendricks/Sigil

has been updated to pull in all of the Qt6.2.2 and Python 3.9 fixes along with all of the required Qt 6.2.2 patches and build instructions.

So if you clone master on that site or download a zip, you should get Qt6.2.2. patches and build instructions in Sigil/docs/. There are also new build instructions to build Python 3.9.9 with its own embedded TclTk and PySide6.

Once those patches are applied Qt 6.2.2 should build out of the box on Apple's M1 (arm64). Python 3.9.9 should also build out of the box on Apple's M1 (arm64) and of course we have updated the Sigil master to work with both Qt6.2.2 and Python 3.9.
No universal builds should be needed and most if not all of the prerequisites can be be either built from source or installed via HomeBrew.

See:

https://github.com/kevinhendricks/Si..._on_MacOSX.txt

and

https://github.com/kevinhendricks/Si..._on_MacOSX.txt

and the qt622_*.patch files and python_3.9.9_fixes.patch in

https://github.com/kevinhendricks/Si...ee/master/docs

I have built this all from source on macOSX 10.15.6 with XCode 12.4 on x86_64 and tested it and it seems to work well.

All of these changes will make it into Sigil-Ebook Sigil master sometime after the holidays.

Hope this helps make Apple M1 arm64 support a bit easier.

KevinH

[democrite]

Thank you very much Kevin.

Indeed such will be much easier. I went thru it and it looks good. A few typos such as "patchg" and I think it was the Monterey Qt patch that is in qtbase/src instead of src, form what I recall. As you know, Sigil instructions weren't there yet, with new options such as "-DUSE_QT6=true". I also noticed it seems at some point Xcode aliases the sdk so one can just use "MacOSX.sdk" instead of the specific version; maybe that started with 12 or 13. I believe also for arm64, perhaps one needs to set a target of 11.0 (I used 12.0). Trying what was mentioned, 10.?, which I didn't do before, there was some Python error of not finding some symbol or library; I believe to be expected.

For some reason the python script that runs after the Sigil make is erroring for me. I briefly look at and am not sure why it behaves as such:

build_fwk [..]/libraries/Frameworks/Python.framework
pversion Python.framework
stdlib_dir [..]/libraries/Frameworks/Python.framework/Versions/3.9/lib/python3.9
stdlib_name python3.9
app_dir [..]/build/bin/Sigil.app/Contents/Frameworks
Traceback (most recent call last):
File "[..]/build/bin/osx_add_python_framework6.py", line 251, in <module>
sys.exit(main())
File "[..]/build/bin/osx_add_python_framework6.py", line 210, in main
copy_python_tcltk(tcltksrcdir, tcltkdestdir)
File "[..]/build/bin/osx_add_python_framework6.py", line 60, in copy_python_tcltk
for x in os.listdir(src_dir):
FileNotFoundError: [Errno 2] No such file or directory: '[..]/libraries/Frameworks/Python.framework/lib'

Maybe you have an idea. Or, maybe I missed something.

[KevinH]

I fixed the typo "patchg" -> "patch" and added qtbase to fix the Monterey patch.
I have added a Building_Sigil_On_MacOSX_With_QT6.txt to the docs/ folder.

This has all been pushed to my github site (see above).

There appears to be an issue with differences in the python3.9.9 build environment or builds.

The osx_add_python_frameworks6.txt is being passed in the wrong values from the build which in turn is causing problems.

This typically happens when the special relocatable Python 3.9.9 is not found first in your path.

For example: my successful build returns:

build_fwk /Users/kbhend/devpython/libraries/Frameworks/Python.framework/Versions/3.9
pversion 3.9
stdlib_dir /Users/kbhend/devpython/libraries/Frameworks/Python.framework/Versions/3.9/lib/python3.9
stdlib_name python3.9
app_dir /Volumes/SSD-Drive/repo/build9/bin/Sigil.app/Contents/Frameworks

which differs from what you showed.

Your build_fwk is wrong which leads to many problems, with the version now not being identified or the proper python3.9 folder, etc.

Did you build Python 3.9.9 following the instructions or did you use something from HomeBrew?

Are you sure the relocatable Python 3.9.9 is found first in the path?

[democrite]

Unsure too. Very possible I did something wrong, yet for me "sys.prefix" returns ../3.9 so I just edited the relevant line and it builds fine.

Quick impressions: dark mode issues still though a bit different. contextual menu text color is fine unlike the older build, yet table alternative row colors is weird like before. maybe i'll try to take a look at the qt bug database and look for any mentions.

[democrite]

Concerning dark mode issues, I haven't had a chance to look too much. Maybe it is only tables with alternate row styling, e.g. editing TOC and the Plugin list in preferences.

The only possible relevant issue I could find:

QTBUG-80757: QTableWidget Palette Returns Wrong Alternate Row Color
https://bugreports.qt.io/browse/QTBUG-80757

Then there was at least one other about native styles though I didn't read it too much. Maybe it is related to SigilDarkStyle? I didn't look to see where it is called. Maybe with creation of each EPUB document? Seems in such cases, maybe sigil dark mode is set. For instance with each, it seems the table styling is incorrect, yet after I toggle dark mode, I think it retains the correct style. I haven't tested much but that seems to be the behavior. Perhaps with Qt6, you could sometime experiment with using the native style w/o changes and perhaps that enough might work?

[democrite]

I really am not sure. But trying to look and guess, maybe the initial detection of dark mode to call fixMacDarkModePalette in MainApplication isn't correct, so it is only called on palette change for switching to dark mode. Or maybe it's something else. Concerning detection of dark mode, there's this for 6.2:

https://codereview.qt-project.org/c/qt/qtbase/+/375648

Yet I use another Qt 5.15.2 app that has no issues of alternate row colors. It's doing something differently.

If that is it, one linked bug notes "Use new QPlatformTheme::appearance() function Instead of qt_mac_applicationIsInDarkMode()", of which the later I'm not sure what it's referring to. Another example is this using the native API:

https://successfulsoftware.net/2021/...t-application/

[KevinH]

I can recreate this issue with my own Qt6.22 on x86 _64 and Sigil. Something is changed in how Application palettes are used in Qt6. I will track this down and get it fixed. I checked how we currently detect if light or dark and it works just fine. athe issue is something else.

[DiapDealer]

For the record: the Windows dark mode seems to be fine with Qt6.2.2. I had to make one small tweak to our code (something keeps changing from pre-Qt5.15 to 5.15 to 6), but I doubt it's relevant to Qt's more inherent macOS dark theme handling.

[KevinH]

The problem is the main qApp->pallette() is not being changed only the macos theme standard pallette. So I need to ifdef some code in CV to not grab and set the pallette from qApp on macOS after a change.