Hi all, since I kicked off a whole long discussion about this back in May (see below), I thought it would be worth an update from me, as a gentoo user, about how things look for my side.
Gentoo dev on my original bug report (here: https://bugs.gentoo.org/926681) just replied that "qt6 porting was merged last week" and so this is "just missing a release." I don't know what that means, but maybe there's the possibility to get frescobaldi ported to use Qt6, at least on Linux systems, now? Cheers, N. Andrew Walsh er/ihn/ihm/sein | he/him/his Berlin (neue Adresse | new address: n.andrew.wa...@proton.me) On Monday, May 6th, 2024 at 15:53, Jean Abou Samra <j...@abou-samra.fr> wrote: > > I’m wondering if the Frescobaldi approach is actually working out. Keep in > > mind that originally Frescobaldi was just a project for adding support for > > Lilypond to KATE, then it became a KDE parts solution, then it started to do > > everything itself for more control. And this means you’ll need to maintain > > and > > develop many components for a niche community. Frescobaldi is essentially a > > full text editor, solely for Lilypond. And I do not think the Lilypond > > community is the best place for maintaining a whole text editor. > > > > This also means you get a weird dependency situation which is hard to > > maintain. Frescobaldi has a lot of qt-independent functionality, including a > > reduced Lilypond parser and transformation tools and stuff. And it has a > > lot of > > interface stuff. This is the part that depends on qt5, and only one > > component > > depends on the poppler integration. > > > > So maybe instead of trying to maintain this collosus of tools it could make > > sense to split it up into different parts: > > > > → An LSP server > > → A transformative toolset > > → An editor using these features > > > > This way no matter what might happen to Frescobaldi, much of the > > functionality > > would be still usable. With an LSP server any modern text editor with an LSP > > client could benefit from understanding Lilypond syntax. And being able to a > > toolset would make extending editors much more fun. > > > > And this way the maintainance effort could be split. Maybe the LSP could > > even > > become part of Lilypond itself (no need to implement a new parser if you > > already have one), keeping it always up to date (rather than the always > > outdated approch we have with Frescobaldi). > > > > Well, what you call the "transformative toolset" is already separated, in the > form of the python-ly package. An LSP server might be nice, but it wouldn't > really take off that much functionality from Frescobaldi. I'd have to check > how advanced the LSP protocol exactly is now, but you definitely can't do > things like the MIDI player, the fonts dialog, or the manuscript viewer > through LSP. > > And of course, if we already have trouble maintaining the software as it is, > finding people to work on that kind of split is not going to be easier :( > > Also, you cannot really use the LilyPond parser because it won't parse > LilyPond code without also interpreting it at the same time (e.g., music > functions can be defined dynamically). You don't want to pay the price > of parsing the full file every time a character changes, and you don't > want to lose syntax highlighting as soon as there is a syntax error.
