CR 3: Change plugin framework

Customers

• Plugin developers

Current state

RViz currently uses a custom mechanism for locating and loading plugins based directly on ros::package::getPlugins and dynlib.h, which comes with wxWidgets.

Problem Description

The non-standard way of doing plugins requires additional documentation, make the learning curve for plugin developers steeper and makes the knowledge about RViz plugins less transferable.

If RViz will stop using wx, then we will need a different plugin system anyway.

Proposed Solution

• Switch to other plugin system
• Write documentation

Alternative plugin system options and their pros/cons:

• Keep existing rviz-specific plugin system.

• gmodule is a cross-platform module-loading system. Part of glib.

  • API is in C. Not clear how well would handle C++ classes.

• ROS pluginlib

  • Based on poco project library.

  • C++ API
  • Adds ROS package path searching machinery.
  • (Dave's favorite option)

• Qt's plugin system

  • C++ API
  • Handles Qt's metadata (signals and slots and reflection)
  • Ties plugins to Qt. Using any other option would let us re-use things like Display plugins in non-Qt uses of the future-rviz graphics code.

• visualization_engine: contains a package named rve_dynlib