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). Cheers, Valentin Am Sonntag, 5. Mai 2024, 22:37:35 MESZ schrieb Jean Abou Samra: > > 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)... > > GSoC projects are nice for doing focused work on some specific part > of the code base. For overhauling just about everything, I'd be a lot > more skeptical, especially since there will unavoidably be fallout > to deal with afterwards in terms of bugs, and that's less nice to do > if the person who did the port isn't available after the summer to > do that part of the work.
signature.asc
Description: This is a digitally signed message part.
