Title of plugin is sometimes wrong; parsing code is very fragile because of assumptions

[cbjeukendrup]

Issue type

UI bug (incorrect info or interface appearance)

Bug description

No response

Steps to reproduce

Install this plugin:
tin_whistle_tablature_v4.qml.txt
(remove .txt from the name)

Then look in the list of plugins (Home > Plugins). Instead of the correct name of the plugin, which is "Tin Whistle Tablature", some random string that occurs somewhere in the file is displayed: "No Staffs use a Tin Whistle"

Screenshots/Screen recordings

MuseScore Version

master (4.4)

Regression

Yes, this used to work in a previous version of MuseScore 4.x

Operating system

*

Additional context

Instead of loading the plugin using Qt itself, we try to parse it as a text file, and do so in a very naive way (see ExtPluginsLoader::parseManifest). Of course, that might speed things up a little bit, but probably not a lot, and it is very prone to problems like this. To fix such problems, we need to make the parser more and more sophisticated, and then it becomes a kind of clone of Qt's QML parser, except that it's probably less optimised. And it takes us an enormous amount of time to implement. So I would suggest just using Qt's parser by loading the file as a QML object. That will potentially result in helpful error messages as well, in case a user has created an invalid plugin.

[igorkorsukov]

I fixed the parsing..

Yes, there are assumptions and that's why the code is fragile..

But I believe that it is not necessary to complicate it without an obvious need, it is better to bring plugins to one style..

Because this is simply needed for backward compatibility, soon we will declare old plugins obsolete and they will gradually disappear.

[TeeDeeY]

Because this is simply needed for backward compatibility, soon we will declare old plugins obsolete and they will gradually disappear.

I think it is helpful to know when old plugins will become obsolete. How much effort should I put into fixing a 3.6/4.2 plug-in into a 4.4 plug-in, if it will be obsolete in six months?

I understand progress and would like to know how best to allocate my time.

[igorkorsukov]

@TeeDeeY

Because this is simply needed for backward compatibility, soon we will declare old plugins obsolete and they will gradually disappear.

I think it is helpful to know when old plugins will become obsolete. How much effort should I put into fixing a 3.6/4.2 plug-in into a 4.4 plug-in, if it will be obsolete in six months?

I understand progress and would like to know how best to allocate my time.

I think it will be like this:

• In version 4.5 we will declare the old system obsolete (but we will support its operation)
• We will support the operation of the old system until version 5.0 at the latest, unless there are very serious reasons to stop supporting it earlier. i.e. the old system will be operational for about another year.

Porting from the old system to the new one is not very complicated, i.e. you won't have to rewrite everything from scratch, but some changes will need to be made.
We will prepare documentation about all this.