Hi! This post is a summary of my Google Summer of Code project, and it also serves as an introductory material linked in The GSoC project page.

The project is devoted to improving the plugin facility of MuseScore, and more specifically, automating the process of downloading and installing MuseScore plugins. The above project page already gives a good explanation for its purpose.

Demo

This is a video demo demonstrating all major features the project covers.

I began by opening the plugin store in Resource Manager, and then downloaded a dozen of plugins in parallel. Then I switched to the "Installed Plugins" tab, where the plugin manager lay, and toggled all the plugins I had downloaded. Then I demonstrated the operations of deleting plugins.

Product Description

The work product contains a plugin store and an improved plugin manager. Both of them reside in a new tab in Resource Manager called "Plugins".
There is a full feature list available at the pull request. Following are some general descriptions for several submodules.

The plugin store.

As planned in the original GSoC project description, I have implemented searching, filtering, (un)installing and updating of plugins from the MuseScore plugin repository. All these operations should be straightforward.

The plugin store internally uses many web crawling codes, and is able to download plugins stored in both GitHub repos and musescore.org attachments. Some of the crawlers are used to fetch the list of plugins from the plugin repository, and others are used to extract download addresses within musescore.org plugin pages or GitHub repos.

In order for the crawlers to correctly locate one plugin's download address, I developed a scoring algorithm to choose the most probable address among all download links matched by regular expressions. Along with this, in order to avoid ambiguity and make implementation simpler, I assumed a set of format guidelines that plugin publishers should obey when creating plugins in the repo, described at https://musescore.org/en/node/286338#comment-925465.
The algorithm has proved very effective, since almost all plugins got downloaded correctly, except for those with wrong formats.

The new plugin manager.

It is an adaption from the old one, which now supports management for both plugin packages and local plugins.

One significant change is that, the list view has been replaced by a tree view, then the hierarchy between plugin packages and their qml files can be represented correctly.

From the implementation aspect, there's one more thing worth mentioning: As before, the plugin manager is always created when MuseScore starts, while the resource manager is created only if the user clicks on the menu button. After the adaption, however, UI elements of the plugin manager are held by the resource manager, so we need to assign those UI elements from the resource manager to the plugin manager at appropriate times. There're more details in this week report.

Multi-threading support.

The implementation exploits thread-level parallelism that the Qt library has provided. Multiple downloading/installing/updating/checking for update processes are all run in different threads, which makes operations in the plugin store much faster.

I have also applied multi-threading to the process of loading extension and language tables when Resource Manager starts, which greatly improved the launch process of Resource Manager.

Code Status

All the project code is located in this pull request. (not merged yet by August 20th)

The PR is not merged yet, but lots of reviewing have already taken place.

Evaluation

When writing the proposal, I classified feature items into basic and advanced ones(there're in the pull request). And now it's delighting to see that all basic items are implemented robustly. However, only half of the advanced items have been implemented. The other half of items are abandoned(you can see those deleted items as crossed texts on the PR page). Some of them were thought to be unrealistic, or not likely to be stably implemented during the coding period.

In general, I would consider the project being complete, as the plugin store self-complete, and indeed offers a convenient way of installing plugins compared to the traditional method for most users. I would expect the work to benefit those MuseScore users who have never visited musescore.org or get exposed to online plugins. Because the cost of downloading a plugin would become much smaller, one would be very much likely to try out new published plugins in the resource manager.

Future work

Here's a list of possible improvements I've thought of.

• Maintaining the stability of various crawlers

  As the number of plugins grows, the web crawlers inside the plugin store must be maintained constructively.

  I believe there will not be serious big crawling/parsing failures which affect all plugins, because the link format and the HTML table format on musescore.org are not likely to change. Nevertheless, if they do change in the future, I'm willing to fix :-)

  What needs to be considered more is some edge cases which may appear in a minority of plugins in future. Then the crawlers will need to be updated if their formats are considered as common ones.

• Automatic update checking

  In the "MuseScore Preference" dialog, there're already options to check for new versions of MuseScore and its extensions. Once these are toggled, MuseScore will notify the user if there's update available. I somewhat mentioned the idea about plugins in the original proposal, and indeed implemented background update checking, but there's no update notification yet. Maybe there needn't to be, since language packages don't have it either.

• Caching the scrawling results

  Before the plugin store starts to download each plugin, an analysis procedure must be run for several seconds. Since those analysis results are not memory-costly, we could cache those results even if the user doesn't mean to download those plugins. By using cached results, we could also avoid the rate-limits set by GitHub APIs.

More information

The discussion thread where we discussed some approaches used in fetching.
Original application materials.
My MuseScore blog contains week reports which describe weekly progress of the project.

The PR and my GitHub account.

Thank you!

songchaow