rviz

SIG Coordinator: Dave Hershberger

Topics:

• RViz
• Interactive Markers
• Plugin API
• Possible move to Qt

Members:

• Dave Hershberger
• David Gossow
• Michael Ferguson
• Adam Leeper
• William Woodall

Discussion

This section contains questions and answers that lead the decision-making process.

General Discussion: RVE, Compatibility, Ogre, Qt etc.

Users: Who are the users of RViz and what are their requirements?

Results

• RVE is discontinued and will not play a role in future RViz
• The move to Qt is not necessary, but will bring long-term benefits: a larger developer base, easier development of future functionality, improved look-and-feel for the user.
  • Edit: Moving to Qt will likely ease the OSX port of RViz, and the refactoring will likely look different under Qt than wx, so we have decided to bump the Qt port up to the front of the priorities.
• Ogre might not be the best choice of rendering library, but switching away from it will mean to start from scratch.

• Improving the documentation, refactoring code & cleaning up the API of RViz will solve a lot of the current problems.

• The main goal for the next release will be to move to Qt, not to add much functionality.
• All changes will be made in a separate code base, as there is a lot of code depending on RViz.

Change requests

CR 1: Improve RViz API and package structure

Create a public API in RViz and separate functionality into modules. Document and write tutorials on how to write a plugin.

CR 2: Change GUI framework

Switch to Qt instead of wxWidgets.

CR 3: Change plugin framework

Switch to a standard way of discoering & loading plugins.

CR 4: Programmatic control over RViz

Give developers the possibility to have control over look-and-feel, camera angle etc. in RViz, creating their own task-specific RViz version.

Other CRs

Not decided on or will not be included in this release.

Action plan

1. Create a Qt version of the base RViz app

   • Switch from RViz plugin finding&loading to pluginlib

2. Make the plugins work with the Qt version (Probably you can't/do not want to hide Qt from plugins)
3. Clean and document the "librviz" API, officially support people making rviz plugins and using rviz classes in their own apps.
4. Make other stuff pluggable, like view controllers etc. (we had this discussion earlier this year already)
5. Finally, you should have a system that allows them to put together all those components including their own displays, view controlles etc. and hide the config options from the user. This would enable the "custom" visualizer apps requested by some people.