GSoC 2019: Plugin Manager (Week 0)

Posted 5 years ago

There's still a week before the official coding period begins, but I'd like to share the progress.

What I've done

I'm not coding full time recently and do have other engagements these days. However, I just keep adding small code snippets regularly.

  • Implement the checking update routine for plugins stored on GitHub.

    The auto-updater is now able to keep GitHub release ID numbers or commit hashes in a file named "pluginpackages.xml" in the data directory. And the routine will return true if there's new releases or new commit hashes found from the web, and in turn enable the "Update" buttons.

    However, the routine can only be triggered by a button currently. Future work will be integrating the routine into the background.

  • Searching and filtering facilities.

  • Clickable plugin names, which direct to the plugin detail page.
  • Some bug fixes.

  • Test for all 3.x-compatible plugins in the repository. (See here for the detailed result)

    There're about a half of 3.x plugins that the store fails to download. The most common reason is that download procedure for links from musescore.com is not implemented.

    As written in the result, there are also problems sometimes even for GitHub plugins:

    1. some plugins are not qml format(they are javascript libraries used by plugin developers, therefore cannot be run directly by users).
    2. there are GitHub repos that contain multiple plugins, or the same plugin with multiple versions.

    Ideas on how to treat them are welcomed:) Personally, for 1, I would prefer to ignore those non-qml plugins in store; and for 2, I would encourage developers to make separate repos for each plugin, and make separate branches for each plugin version.

UI Demo

ui-demo-week0.png

What to do next

If everything related to plugins from GitHub goes well and nothing controversial happens, I plan to work on the download routine for plugins stored on musescore.org. I'll probably start by implement for plugins stored as attachments first.

As before, any feedback is welcomed!

Comments

• May 23, 2019 - 15:08

Please check how the extensions tab in the resource manager looks/works, there are alway 2 buttons, which enable/disable/change lable as needed, one for Install/Update, and another for Uninstall.

I assume the real thing will use a nicer font, right?

Reply

• May 24, 2019 - 16:25

OK, I'll make the buttons consistent with those in the extensions tab, and prepare 2 columns for buttons.

I've checked that the fonts from the extensions tab and the plugins tab are probably the same. But my patch seems to have anti-aliasing disabled somehow. I'll investigate the reason.

Reply

• May 25, 2019 - 23:37

Where are plugins located currently? It seems to be all over the Web. I think you should develop the plugin manager to find plugins only in one unified place, and if a plugin author wants to have his plugin show up in the manager, he has to host it in the central hosting repo. That will make your work a lot easier, because then you can also control the requirements of the code format and such a lot better.

Reply

• May 26, 2019 - 06:46

Most plugins are now located on GitHub or musescore.org. I would suggest using GitHub as the unified location, but supporting attachments within plugin detail pages is also possible. Since attachments are quite common in existing plugins and downloading them accurately is indeed achievable, I prefer to consider both.

"he has to host it in the central hosting repo"
However, containing all plugins in a single repo may break the workflow very much, which is probably not likely to be adopted immediately.

Reply