> unfortunately, as I noted above, the problem seems to be that frescobaldi > depends on a now-deprecated version of qtwebengine, and without updating > it we'll eventually reach a point where it no longer runs. I looked into > this because qtwebengine-5.15 failed to compile on my machine this morning, > so I'm worried we're already approaching EOL on it.
Note that we're talking about Qt as a whole, not just QtWebEngine which
is just a small part of it (well, for some definition of "small" since it
embeds Chromium's Web rendering engine…) that Frescobaldi only uses in a
few places (IIRC, the SVG viewer and the documentation browser).
Qt 5 *is* already EOL upstream, since May 2023.
> Jean: I have a colleague who does UI work and is "fairly" capable of dealing
> with python and Qt dependencies. Can you give me a brief (but as technical
> as it needs to be for a specialist to understand the issue) summary of where
> the sticking points are?
Frescobaldi uses the Poppler library in order to display PDF files. (It cannot
use Qt's native PDF viewer based on Chromium, because that one is not powerful
enough to support point-and-click.) Since Frescobaldi is written in Python and
Poppler is a C++ library, it needs an FFI wrapper, which is called python-
poppler-qt5 and written with a tool called sip that is developed by the
creator and maintainer of PyQt itself and also used for PyQt.
Thus there is a diamond dependency:
Qt5 --------------> Poppler (C++)
| |
| |
| |
v v
PyQt5 -------------> python-poppler-qt5 (Python extension modules)
python-poppler-qt5 is a little fiddly to build: it's multiple layers
with sip generating C++ code and QMake project files, then QMake
generating a Makefile and sip finally executing make on that Makefile.
On macOS, the platform favors distributing applications as .app bundles,
which are optimized for being created by the native app development
tools (Swift+XCode). These have a peculiar structure organized into
"frameworks", with data files separated from code files, shared library
lookup paths modified and that sort of thing (the specifics I do not know
or remember). Of course, that doesn't play well with Python packages
relying on a different structure, and Qt + PyQt also needing their
file structure. In fact there are whole tools written just to deploy
PyQt in a .app bundle, see pyqtdeploy.
Now throw python-poppler-qt5 into the mix, which needs to be loaded by
Python and find its linked Poppler and Qt and PyQt, and you should start
to understand the problem.
Basically, it's the Apple flavor of "things will work well but only
if you do it my way with the non-cross-platform tools from my walled
garden" in its full glory.
Add that macOS displays scary warnings to users if the app bundle
hasn't been signed with a certificate that costs real money.
Details are on
https://github.com/frescobaldi/frescobaldi/issues/1584
Also add that the tool Frescobaldi has used so far to create app
bundles, py2app, relies heavily on setuptools, which prevents
Frescobaldi from moving to a more modern and less complicated
build backend like hatchling.
Apart from these packaging issues, there's also an issue with
the global menu (the one at the top of the screen on macOS, it
doesn't appear on other platforms) which isn't really up-to-date
and has been a source of crashes.
There are also miscellaneous bugs that only reproduce on macOS
(they have the macOS label on GitHub) and it's not always easy
to understand why.
Well, the explanation wasn't that brief. Sorry that I didn't have
time to write a shorter one, as they say.
signature.asc
Description: This is a digitally signed message part
