Closed kontur closed 5 months ago
Hmm, can you try with pyobjc==10.2 instead of the current 10.3? That init thing may be a clue. Yup, that's the one, I'll file a pyobc bug :( We need to pin to 10.2 for now.
Correct, but even then I'm seeing the described v1.8
behaviour. E.g. now I get the app window default, but when loading a font it flashes and immediately crashes:
https://github.com/justvanrossum/fontgoggles/assets/1893577/e36b0acc-7e95-437b-ab53-e8e462dd9209
I'll work the commits backward to see where this came from, or where the last working one can be found.
Okay, trying to further debug I simply cannot find a version I can go back to that does not crash or fail to install :(
I switched to python 3.11.2 to get around the 1.7.4 install issue with harfbuzz, and I am downgrading pyobjc to 10.2, and I am using fresh virtual environments after each commit, but even then:
813b751f34f1df24324ec5639cf70d8fe6dcaa6b Bump vanilla
is the last where: app starts, default window opens, but opening a font crashes the appAttributeError: 'super' object has no attribute 'dividerThickness'
(I suppose due to some kind of requirements mismatch to the used syntax)objc.BadPrototypeError: '_windowCloseCallback' expects 0 arguments, <function FGMainWindowController._windowCloseCallback at 0x10b9244a0> has 1 positional arguments
— I suppose this could be the pyobjc downgrade, but then I tested with explicitly lower, previously pinned, versions down to 8.5 without luck)So in a way the "Bump vanilla" commit was the last one where at least the default window would open, but even then/before that there is some other bug that crashes the app on font load, but I cannot pin it down due to other dependency issues.
🤷
Soo... the "default window" opens is indicative of nothing else but if the app was last open with an empty window, I suppose. Since I was switching commits, rebuilding, it would always open the app with without the default window. Not sure if it ever did, by default, open an empty app window, of it that is just me misremembering.
If I make a new build, switch to the app, ctrl+n and I get the default window, then re-building, the app will open with the default window. So that means nothing; just the "open font and crash" -issue remaining. 🫤
It should always open a new window, even if there was no window open when you quit. (Unless that behavior changed in the OS, but I don't see it in macOS 14.2.1)
Hm, no idea about the window opening.
In the meantime, this is the exact line the app crashes from, without any error.
Printing out gid, path_p, path_capsule, funcs
just before the call yields (not sure if that is helpful at all):
5 4879507568 <capsule object NULL at 0x1218e8120> <uharfbuzz._harfbuzz.DrawFuncs object at 0x1097cc460>
I've tried with a previous version of harfbuzz but to no avail. Also this happens for any font it try. Could my brew installed harfbuzz interfer here, or something how my python is installed linking to some library? I'm still not clear on why the released v1.8 works, but my local dev compile does not.
Or maybe the "turbo" lib needs to be rebuilt?
./Turbo/build_lib.sh
You mention brew: is brew anywhere else involved in your Python setup? Apart from having the harfbuzz lib installed with brew: to the best of my knowledge that should not be a problem.
Oh boy... it's literally right there in the README for editable mode. This was painful. And embarrassing 🤦
Sorry to have wasted your time to help debug this.
(Also loads with a new window now...)
No problem, I'm glad it works now!
Building the app from source fails in the current state (b36325a). This expands on issues noted when revisiting #300 / #25.
Environment
I have a hunch this is related to py2app build targets / M1 chips. I'm building on a Apple M1 Max with Mac OS 14.5 (23F79) and Python 3.12.2.
Observed behaviour:
For a fresh install with:
Performing the same install and build at v1.8 the observed behaviour is slightly different, but also buggy:
And trying the same again for v1.7.4 the install fails somewhere in pip installation with the harfbuzz dependency:
So for now I can't actually pinpoint a version that installs and runs, but clearly something in
v1.8
is already off, and currentmaster
fails even more. I don't think the issue withv1.7.4
not installing is the issue, that's likely just dependencies needing newer versions.Interestingly, the released dmg version of
v1.8
runs fine on my machine.