GSoC 2019: Plugin Manager (Week 1)

Posted 5 years ago

Hi, sorry to be late. Now it's already the second/third day of week 2 in GSoC coding period, depending on your time zone.

What I've done

  • Make the button style in plugins tab consistent with the extensions tab.

There're now always 2 buttons for each plugin. One is for install/update and the other is uninstall. Also, the buttons are now stretched to fill up the table widgets.

The fonts' anti-aliasing should be enabled if you are not debugging the application, which can make the display much smoother.

ui-demo-week1.png

  • Add codes to detect attachment links from the plugin detail page.

The routine can now return a list of filenames and URLs. Currently only URLs from the explicit "ATTACHMENT" box are collected. To increase flexibility, I'll consider the option of collecting inline URLs, which should be easy.

What to do next

I plan to further work on the download routine for plugins stored on musescore.org. The following features are planned in the next week:

  • Ability to get timestamp of the downloaded file from musescore.org.

  • Implement the basic download workflow.

  • Start to discuss the possible attachment forms(a single archive? one or multiple qml files? and naming of different plugin versions) that the auto-updater should accept.

Comments

• Jun 5, 2019 - 07:23

I wonder whether we need that Compatibility column, or just filter on 3.x instead? After all the 1.x and 2.x plugins won't work anyhow?
Also what is the 'Installed Plugins' Tab good for, if one can see in the other tab already which plugins are installed?
Nit-pick: that Check Update button should rather be Check for Update, if needed at all and not just done under the covers when starting that dialog, like it works for languages and extensions

Reply

• Jun 6, 2019 - 12:47

the compatibility column indeed provides redundant info. The project might cover 2.x plugins later, but 2.x plugins can be marked by other approaches, and don't indeed need an entire column to show the difference.

As for "Installed plugins", My thought was that features from the old plugin manager, which are for local plugin management, could be moved there.
This way, the workflow of installing, enabling plugins and viewing plugins' details could all happen in one dialog. But I'll accept it if the majority prefers to keep the old plugin manager from being moved.

The "Check (for) Update" button is now only used for debugging and not designed for normal use. And I indeed plan to trigger the checking routine when the dialog starts. And the checking routine is quite time-consuming and should probably not block the resource manager's launch process.

Reply