no luck with PyQt5 via pip. An error is reported here. If I was more familiar with Python, perhaps I'd know. I thought I had it working before with sip 5.5.0, or maybe it was some older 4.x. Didn't note that down so forgot.

https://bugs.kde.org/show_bug.cgi?id=444857

Not giving up but it has been sometime with various detours and setbacks. For now, I'm going to try all dependencies via MacPorts. Despite any lack of patches, maybe it'll work well enough. Otherwise, I might wait a bit before trying again.

No worries. We can host our own Qt 5.15.X tree and collect and commit all of the patches you have found so far. I will update my laptop to Big Sir (I always try to stay one release back any way) and try cross-compiling Qt to arm64.

Alternatively, We have started to modify Sigil master to support both Qt6 and Qt5 from a single codebase. I have opened a tracking bug for that. That way if worst comes to worst, we can try with Qt 6.3.0.

So hang on a couple weeks as I can only sit for an hour or so at a time.

Very happy to hear that. Thank you Kevin.

Concerning the struggles I've had, perhaps I just needed to step back and think about each problem and where to find more info, rather than sitting there and trying different things without knowing if such would work.

Eventually I found a mention of the latest PyQt5 breaking compatibility with sip 4.x. Not fixed yet though it might be in the dev branch, thus it was a bit difficult to discover. Using PyQt5 5.15.5 works, and no issues with PyQtWebEngine 5.15.4.

https://groups.google.com/g/linux.de.../c/FdgUVpZ4SWE

It was a bit frustrating being unable to find different builds of sip, PyQt5, and PyQtWebEngine. I think various distros might keep archives, such as this I found from MacPorts:

https://distfiles.macports.org/py-pyqt5/

Thus, maybe the only issue, at least that I can recall at the moment, is QtWebEngine on Monterey. If the MacPorts edition will work, I'm not sure yet. Perhaps I may try to grab their patches and manually apply them if possible, depending on how I feel in the coming weeks in trying to complete the build.

So, thinking that maybe all prerequisites are satisified, I tried the Sigil build. Perhaps such is from an error on my part with building Python 3.9.9, yet I went over it again, yet possibly I still missed something. make -d returns the following error:

Seems that the bin folder is misplaced. From the Python instructions, I believe it ended up being in the same folder level as Python.framework. Moving it allowed me to skip past that error though I'm unsure if that is ok. I think it's not as Sigil crashes on start, unable to find Python:

Of make addframeworks -d, there are various errors such as this:

Of that I couldn't find much info yet.

Getting close.

To use Python 3.9 you will have to modify the sigil_constants.cpp file that looks like this now, changing the 3.8 to 3.9 in the right places.

Apologies for something I should have been able to figure out.

Good news. Sigil is built. Tested a few things including converting to EPUB 3. So far so good.

Earlier, Sigil would crash on start without any log. From a shell, running Sigil.app/Contents/MacOS/Sigil listed some message about not finding the python encoding library. Maybe I missed something still despite going over it several times. Also found a few other refs to Python 3.8 in make files. Within Python.framework, there was no Versions/3.9, only Versions/Python.framework and Versions/Current. Adding a symbolic link fixed that.

I ended grabbing the MacPorts QtWebEngine 5.15.7 patches for Monterey mentioned earlier:

https://github.com/macports/macports-ports/pull/12595

That compiled fine. QtWebEngine is now at 5.15.8 though I didn't test it.

One additional patch was to remove the hardcoded x86_64 build arch from the qmake conf files. There's two listed from MacPorts, for pre- or post-install:

https://github.com/macports/macports...aqua/qt5/files

Trying to recall prerequisites that didn't compile for arm64, I think it was libpng rather than the xz mentioned earlier. Installed thru homebrew. Besides that, I think all patches are listed above.

Quite a bit of trial and error, particularly since I was unfamiliar with the various tools and haven't compiled anything myself in sometime. Yet now all is good and I can return to reading, making, and editing ebooks. Many thanks Kevin and DiapDealer for the assistance.

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.

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.

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.

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.

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.

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.

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

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:

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

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:
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?

Sigil on Apple M1 running under Rosetta 2?
 

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.

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?

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/

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.

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.

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.

Sounds somewhat similar. The dark theme for Windows won't change "on the fly" like it will with Qt for macOS, so I only have to do it once. It's in main.cpp. For Windows (and linux, too), it's a matter of calling or not calling:

depending on the Qt version used.

Okay just pushed a bunch of Qt6 on macOS related fixes to Sigil master on my github site:

https://github.com/kevinhendricks/Sigil

These include:

- use absolute path on sys.prefix to get proper path when installing python3 into Sigil

- worked around TabManager and PreviewWindow dark to light and visa-versa change issue
- these were actually early dark mode bugs re-introduced into Qt6 that were long ago fixed in Qt 5.12.x
- probably because they forked for Qt6 before these changes went in and they have not added in these fixes for some reason

Hope this helps,

KevinH

Thank you. Dark mode alternate row color works great and the python script change builds fine. I didn't test Qt 5. I saw a comment about for Qt 5 also so maybe such would be ok. As the dark mode alternate row color issue existed for me with Qt 5.15.2, and it seemed you didn't notice it, maybe it is specific to some combo of that Qt plus Monterey.

A quick look around other parts of the app to verify, I noticed maybe in Preferences, Keyboard Shortcuts could also use alternate row colors.

Testing switching between dark and light mode, doing such while Preferences is open, something else is sometimes the palette doesn't change correctly. It doesn't happen all the time; perhaps it is something new with Qt 6. Screenshot attached.

Since I was looking at Preferences (and other parts of the UI), the slider to set main menu icon size I think looks non-native. Compared to Qt 5, the slider now has hash marks. Screen shot attached plus one from System Preferences.

And unrelated to Qt6, maybe the find/replace panel could use some padding around controls. For example each of the options (DotAll, …) are almost cut off since the next control appears after w/o padding.

The icon size slider, should show the tick marks as it is part of the code and has been. They should show under Qt5 as well, otherwise it is a Qt5 bug.

The Preferences Keyboard Shortcuts QTreeWidget can easily be set to setAlternatingRowColors true in either the code or its ui file. No one has asked for that yet so this is unchanged from Qt5.

I will play around with dynamic switching from dark to light and back in Preferences to see what breaks. But Qt 6.2.2 is actually a big step backward in this regard as Qt 5.12.9 has this working.

Indeed very possible Qt 6 has a whole new set of issues.

Concerning the slider, I found this issue for Monterey yet I didn’t test yet if such happens for me.

https://bugreports.qt.io/plugins/ser...ue/QTBUG-98093

Of the look of the slider, I think you’re using TicksBothSides? I haven’t really looked yet I think on macOS, below might be the preferred choice. At least such seems to be the case from some screen shot from Apple’s Human Interface Guidelines.

From Apple’s API, below and above seem to be the only valid options and I am not sure what Qt does when set to both.

https://developer.apple.com/document...ckmarkposition

Thanks, for that Qt tick mark bug link. From reading it and the related Monterey specific bug we will have to wait for a fix from Qt for that as Qt 6.2.3 will not be released opensource as it is LTS.

As for making Sigil exactly match the Apple native guidelines for tick marks, that is a very low priority as Sigil is meant to be a cross-platform app first and foremost. And function must come before form. We also like to limit the number of platform specific ifdefs in our Sigil codebase as they make support harder because the flow is not easily apparent.

All that said, I will look into changing the tickmarks location on macOS Sigil for some future release.

No prob. All is working well and the main goal of a native build has been achieve. Many thanks again for everything.