Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin

...

Plugin and PluginGui both implement activate and deactivate methods. Deactivation of plugin functionality is not implemented. A plugin should be responsible for cleaning up memory by disposing of objects created in the Activate method of either the pluginGUI or plugin.

I looked at the activation deactivation in Visual Studio. Visual studio expects the plugin to clean up its mess. This does not work satisfactory: a plugin like MZTools removes its menu (as you would expect) but plugins like AnkSVN and Resharper do not. The VS program needs to be restarted in order for the changes to menus and toolbars to take place. Therefore allowing for plugins to manage this does not seem a good solution.

Therefore I would like to suggest the following Activate/Deactivate scenario
rebuild : Rebuild menus and toolbars by querying all plugins for menuitems and toolbar items for plugins with PluginGui.IsActive == true. Currently the menus are build only when DelftShell is created. (InitializeMenusAndToolbars).(currently implemented in DelftShell.InitializeMenusAndToolbars)

In addition the logic for querying Viewproviders and modelproviders should be extended with knowledge about active status of plugins.Viewproviders and modelproviders
When we unload a plugin the modelprovider or viewprovider should not be queried for models or views