GSoC 2019: Plugin Manager (Week 2)

Posted 4 months ago


These days I have been focused on fetching plugins stored on

What I've done

  1. I made some draft specifications on the format of upoaded plugins, including GitHub ones and ones. You can see the detailed specifications on

    The main idea is that one GitHub repo must contain exactly one plugin, and place plugins of different versions on separate branches.

    And for ones, we explicitly do not support the case where multiple qml files are uploaded and each of them is partial to the plugin. If we allow for that case, there would be ambiguity: it would be hard for the auto-updater to tell whether a qml file is partial, or the file itself is a complete plugin of a different version.

    If you have different opinions on this decision, feel free to say:)

  2. A basic implementation according to the specifications above
    So the implementation now covers plugins from

    The fetching routine works like this: Firstly find all attachment links in the plugin detail page, and score them according to text within or around the links. The higher score a link gets, the more likely it is to be the plugin of a correct version(3.x). Then we select the link with the highest score and download procedure begins, and the timestamp in the HTTP response is kept.

A demo

I now realize it's a good idea to provide GIF demos, so I create one below.


What to do next

The implementation should be a very unstable one for now, as I haven't tested it much. So I'll first test for all plugins again and optimize the fetching routine. The optimization should be a long process which may happen across the whole coding period.
Meanwhile, I plan to move the checking update routine into background and make it triggered when the resource manager starts.


Looks pretty good to me, but raises one question/issue: if installing plugins that way, shoudn't they then also get enabled in plugin manager automagically?