The technical stuff is way over my head, but this reads like the top-
level description of a GSOC project (in case the mentioned friend
doesn't take the bait)...

In other threads spawned by this one, there have been some helpful
suggestions for alternative lilypond IDE's, but there is some cost to
lilypond in fragmenting its user experience.  At the moment, we can
just say to new users "choose Frescobaldi; it's the best and most
popular IDE, and it's really easy to install" confident that any
questions that arise will likely be understood and answered readily.


On Sun, 2024-04-28 at 21:36 +0200, Jean Abou Samra wrote:
> > 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.
> 


Reply via email to