Plugin Improvements

List of possible improvements

Here's a list of possible improvements to the Plugins (user interaface and API) to make them easier to use.

• When plugins are loaded, they should be listed in firefox like addons dialog with the name,version and description for the plugin clearly shown (Figure 1). Currently there's no mechanism to provide a user-friendly name or description (and optionally an icon for the plugin). A possible means could be to extend the ADD_PARAVIEW_PLUGIN macro as under

 ADD_PARAVIEW_PLUGIN(Name Version
   LABEL "User friendly plugin name, Name used by default"
   DESCRIPTION "description for the plugin" 
   ...)

This probably goes without saying, but if no label or description is specified, a default one should be created from the Name and Version parameters. --Ken 11:32, 8 June 2009 (EDT)

• Often times a plugin needs components to be loaded on the server side as well. The server side components may be provided by a separate plugin on the same plugin. In that case, we need to provide a mechanism to make the user aware of this fact. A possible solution is to extend the ADD_PARAVIEW_PLUGIN macro as illustrated by the following example:

ADD_PARAVIEW_PLUGIN(PointSpriteServerPlugin "1.0"
  CLIENT_PLUGINS PointSpriteClientPlugin  # <-- Optionally specify the client plugin name(s)
  ...)

ADD_PARAVIEW_PLUGIN(PointSpriteClientPlugin "1.0"
  SERVER_PLUGINS PointSpriteServerPlugin # <-- Optionally specify the server plugin name(s)
  ...)

I'm really, really sick of this pointless distinction of client vs. server plugins. It makes things really confusing for both plugin users and plugin developers. Instead, we should just encourage users to roll both client and server code in the same plugin. The user than has to (at most) only match the plugin on client and server. The ADD_PARAVIEW_PLUGIN options can be simplified to a couple flags that state whether the plugin is required on the client or the server.

ADD_PARAVIEW_PLUGIN(PointSpritePlugin "1.0" REQUIRED_ON_SERVER REQUIRED_ON_CLIENT)

The only reason I have ever found to make separate client and server plugins is an odd corner case where someone compiles a server plugin on a computer that builds the GUI and then tries to distribute that to a server where the GUI is not built. This seems like a pretty weak use case to me since any non GUI build must be done locally from source anyway. In most cases it makes more sense to distribute source anyway. --Ken 11:47, 8 June 2009 (EDT)

I totally agree, the client-server distinction is a major pain, but I thought it's very common to build on the cluster without Qt support -- which is the reason why we are not simply using Qt-based rendering for charts on server side for tile display etc. (or so I thought -- I may be totally mistaken, so please correct me if I am wrong). If that's not the case, then I totally like your suggestion.

True, compiling non clusters without Qt support is common (we have several such builds at Sandia). But the right thing to do is to allow the plugin to be compiled in either environment. That is, you add IF statements in the CMake code to not compile the Qt code if it does not exist. See the pvblot plugin for an example. It would be nice if ADD_PARAVIEW_PLUGIN was a bit more intelligent about ignoring the GUI specific parts of the plugin so that you could reduce the amount of IFs and not have to have two ADD_PARAVIEW_PLUGIN commands for the same plugin. (Perhaps that should be its own bullet point.) However, the plugin CMake itself will probably still have to check for the GUI to know whether it can run MOC, etc. --Ken 13:46, 8 June 2009 (EDT)

In any case, we should should get rid of "GUI" dependencies on simple plugins like filters/readers/writers. These plugins have Qt dependencies for registering extensions, menus etc. which can very well be handled in Server Manager. Thus, unless you are really writing custom panels or display panels or views etc., your plugin shouldn't even require Qt.

I agree, and the current plugin interface supports this (see the Moments plugin that adds filters without any GUI components). At the same time, it only makes sense to "get rid of" GUI dependencies if the reader/filter/writer can be used independently of other GUI controls. It is ridiculous to, for example, put a filter implementation in one plugin and a the GUI panels that control them in another, which is something I see a lot to satisfy this stupid client/server plugin distinction. --Ken 13:46, 8 June 2009 (EDT)

However, Jeff was suggesting they need dependencies on plugins (nothing to do with server-client, just dependencies on plugins eg. the tool bar plugins needs some other filter plugins to be loaded etc.) For that case we may still want to provide a "REQUIRED_PLUGINS argument eg.

 ADD_PARAVIEW_PLUGIN(PointSpritePlugin "1.0" REQUIRED_ON_SERVER REQUIRED_ON_CLIENT
   REQUIRED_PLUGINS VTKPointSpriteMapper)

Utkarsh 13:10, 8 June 2009 (EDT)

That's true. (Scary, but true.) I forgot that point. --Ken 13:46, 8 June 2009 (EDT)

The user interface dialog for the plugin manager then can show warning (with red/yellow highlights) when a corresponding plugin has not been loaded thus warning the user that he needs to load some more components for the plugin to work correctly.

Rather than the stoplight, consider using nothing for a working plugin and a standard warning icon (such as a yellow triangle with an exclamation point in it). I don't think having two error conditions (bad yellow and really bad red) buys us anything, and this icon should better serve to warn users. We also won't have to worry about problems with red/green color deficiencies that stoplight colors bring up. --Ken 11:54, 8 June 2009 (EDT)

• Once a plugin is loaded, the plugin manager keeps track of it. The user can then set options on it such as automatically load on startup. The plugin is remembered until a failed attempt is made to load it in future (just like recently opened files). However, the user can manually choose to remove a plugin from the list.

• Plugins included in Paraview source tree need a mechanism to indicate if the plugin should be loaded when ParaView is to be loaded automatically at startup. Some plugins may be essential to ParaView's functioning once we redesign ParaView to simply use plugins for most of the GUI functionality. Such plugins should not even show up as loaded plugins the the plugin manager since these are not configurable plugins in the truest sense. Overview has a mechanism for this. We may want to use the same.

• Distribution of plugins is another important issue. External parties should be able to distribute their own set of plugins. There are two solutions for this:
  • 3rd Party plugins install like any other application, in it's own directory etc. Then the user is expected to manually load the plugin into ParaView the first time, following which ParaView will remember the plugin and user can configure the options to load the plugin automatically if he wants.
  • 3rd Party plugin installer asks for the ParaView installation directory during install. The plugin can then install itself under the "plugins" directory in the ParaView tree or in users home directory (or some other place where ParaView looks for plugins by default).

I think I am leaning towards the former since it's not intrusive at all, thus leaving the original Paraview installation unharmed.

• Informative error messages. "What is wrong with my plugin" is a hot topic on the mailing list. When a plugin fails to load, there is little output that helps in diagnosing the problem. --DaveDemarle 12:04, 8 June 2009 (EDT)

Current Implementation (Iteration 1)

• ParaViewPlugins.cmake

 ADD_PARAVIEW_PLUGIN(Name Version
    [REQUIRED_ON_SERVER] 
    [REQUIRED_ON_CLIENT]
    [REQUIRED_PLUGINS pluginname1 pluginname2]  
   ...)

New optional arguments for ADD_PARAVIEW_PLUGIN:

 REQUIRED_ON_SERVER is to specify whether this plugin should be loaded on server
 REQUIRED_ON_CLIENT is to specify whether this plugin should be loaded on client
 REQUIRED_PLUGINS is to specify the plugin names that this plugin depends on; 
                  Currently this ARG only allow plugin names, and we should later also allow plugin versions to be specified.

For a client side only plugin, REQUIRED_ON_CLIENT should be specified; For a server side only plugin, REQUIRED_ON_SERVER should be specified; if a plugin has both server and client components in it, REQUIRED_ON_SERVER and REQUIRED_ON_CLIENT should both be specified, which is also the default. If only one is specified, the other one will be set to false. For example, if REQUIRED_ON_SERVER is specified

 ADD_PARAVIEW_PLUGIN(Name Version
    [REQUIRED_ON_SERVER] 
    ...)

This plugin will have REQUIRED_ON_SERVER be true, REQUIRED_ON_CLIENT be false.

• vtkPVPluginInit.cxx.in, pqPluginImeplementation.h.in and pqPluginImeplementation.cxx.in

New EXPORT APIs are added to plugins:

 const char* ParaViewPluginName();
 const char* ParaViewPluginVersion();  
 int ParaViewPluginRequiredOnServer();
 int ParaViewPluginRequiredOnClient();
 virtual const char* ParaViewPluginRequiredPlugins();

This info is used currently by pqPluginDialog to display as plugin information on the GUI.

• New plugin manager in server manager layer: vtkSMPluginManager, which handles loading and managing of server manager components of plugins.

This manager is accessible from vtkSMApplication::GetPluginManager(); From Python Shell, a new arg ("remote") is added to LoadPlugin, which is to specify whether this plugin should be loaded on server (remote == True), or on client (remote == False). This arg is optional, and by default is set to True; for "builtin:" server, however, it does not make a difference.

• Modified GUI

* Visual hints(traffic lights) are added for each plugin. 
 Red, there is either Load Error, or the plugin is not functional due to missing required plugins, or Required_on_server is set, but not loaded on server
 Green, loaded and functional.
 Grey, not loaded yet.
* Right click on a plugin name, will show a context menu that allows to load the selected plugin if that plugin is not loaded yet.
* The "Auto Load" check box is to allow the user to specify whether the plugin should be auto loaded when next time this server is connected. 

• TODO list

1. Add Plugin "LABEL" and "DESCRIPTION" ARGS for ADD_PARAVIEW_PLUGIN.
2. Allow plugin version to be specified with plugin name in REQUIRED_PLUGINS.
3. Some machanism to allow a list of "default plugins" that will be loaded automatically. This may have to be separated from those plugins that loaded from PV_Plugin_PATH and those plugins that user specified "Auto Load" from the GUI.