Additional entry points for new plugins

[mast-eu]

I want to start a discussion about new plugin entry points, to see which ones are of common interest and feasible.

Currently the entry points for plugins are:

1. Execute(): Runs when a plugin's name in the Plugins menu is clicked. This usually shows a dialog for further interactions.
2. Register(): Runs every time when a repo is loaded.
3. Unregister(): Runs when a repo is unloaded, either by switching to another repo or by closing GE.

These work well for the existing plugins, but IMHO can be a limitation for new ones. Thus, some ideas for further, optional entry points:

1. Allow plugins to add second level menu items under Plugins > plugin_name, to run different actions without the need for an own dialog.
2. Perform actions directly from the dashboard, before a repo is opened. Maybe in the form of using the Plugins menu there as well, but passing an additional argument to the plugin to distinguish whether the call comes from the main form or from the dashboard.
3. A plugin-specific toolbox in the main toolbar.
4. From the revision graph context menu, to perform actions on the selected commit.
5. From the left panel, to perform actions on the selected repo / branch / tag.

All of these should be optional. Each plugin should declare which ones (if any) it implements.
This way, backwards compatibility is ensured and the existing plugins continue to work as before.

[gerhardol]

Please coordinate the thinking with moving out plugins from the main application, like in #6415 and #5574

[RussKie]

I created a new project to track all issues related to the topic.

[mast-eu]

@RussKie: Maybe it's just me, but I do not find any project. Where exactly is it?

[gerhardol]

I do not find any project

https://github.com/orgs/gitextensions/projects/3#card-20603187

[pmiossec]

I don't know if it's on purpose but that's not a public project... (page 404)

[gerhardol]

I don't know if it's on purpose but that's not a public project... (page 404)

@RussKie can change

[RussKie]

Please try again

[pmiossec]

That's Ok. 👍

[RussKie]

Few extra API good to have:

• HasUI: bool to indicate whether a plugin should have a menu (e.g. JIRA integration plugin doesn't have a UI)
• IsConfigurable: bool to indicate whether a plugin can be configured by a user
  • LoadSettings: ? - to load settings to present in a settings UI
  • SaveSettings: ? - to save settings

NB: names/signatures are open to discussion

[maraf]

Few extra API good to have:

• HasUI: bool to indicate whether a plugin should have a menu (e.g. JIRA integration plugin doesn't have a UI)

• IsConfigurable: bool to indicate whether a plugin can be configured by a user

  • LoadSettings: ? - to load settings to present in a settings UI
  • SaveSettings: ? - to save settings

NB: names/signatures are open to discussion

What about implement this by querying interfaces?
Like if Plugin class implements interface IPluginsMenuItemProvider or ISettingsContainer..

Or go even further and use more MEF exports, like VS?

[RussKie]

I am not that familiar with MEF, but that may as well work. Will probably be nicer to deal with too.

[maraf]

Hypothetical example: Support for extending GE main menu.

Contract:

public interface IMainMenuFactory
{
    ToolStripMenuItem Create(Context context);
}

Plugin implementation:

[Export(typeof(IMainMenuFactory))]
[Order(After = GitExtensions.MainMenuDefaultItems.Commands)]
public class BundleBackuperMainMenuFactory : IMainMenuFactory
{
    public ToolStripMenuItem Create(Context context)
    {
        var item = new ToolStripMenuItem("Bundles", OnClick);
        //...
        return item;
    }
}

Consument (somewhere deeply inside FormBrowse.cs):

class FormBrowse
{
    //...

    [ImportMany(typeof(IMainMenuFactory))
    public IEnumerable<Lazy<IMainMenuFactory, OrderMetadata>> MainMenuFactories { get; set; }

    //...

    private void InitializeMainMenu()
    {
        InitializeDefaultMainMenu();

        var context = new Context();
        var factories = MainMenuFactories);
        foreach (var factory in MainMenuFactories)
        {
            var item = factory.Value.Create(context);
            var index = OrderMetadataSorder.GetPosition(factory.Metadata);
            mainMenu.Items.Insert(index, item);
        }
    }

    //...
}

(These snippets possibly won't compile)

[RussKie]

I'm a bit hesitant allowing plugins create top level menus, this may get unruly - what if a user installed a dozen of plugins?

I think all plugins should reside under "Plugins" menu, as we currently have. If a plugin has a UI, then a plugin gets added to the list.

At least for now I don't think we should overcomplicate the implementation.