This is a loose list of questions that came up and we need to discuss during our meeting. Feel free to add more.

In the ticket system, there are a long list of other things which could be done.

General Questions

Should this be rolled into ROS GUI?

No it should not. The ROS GUI people want to talk about is more like desktop integration, not visualizing sensor data.

RVE

What is the status of RVE?

The last quote from Josh Faust about RVE is that it was "1/4 baked". I worked on it and with it for a few months and became convinced that he was right about that. Many months of work remains before a new rviz with similar capabilities would come from it.

Is that project abandoned or not?

It is abandoned.

Is there anyone working on it?

No.

Will it be resurrected?

I doubt it.

Are there already users?

The most recent commit to RVE was April 7, 2011 by Javier Romero. If Javier is not using it for his project, then I believe no one is. The other customer was RIDE2, a successor to the RIDE GUI from Bill Smart. I was the only one working on that, and I am not working on it any more.

Are there plans to actually use it at some point for a future RViz?

No.

In my opinion it was a mistake to try and re-write all of rviz from the ground up. Much of the effort that went into RVE (as it stands) went into some pretty elaborate infrastructure, which in my opinion was not really warranted. The entire rendering engine is abstracted, not just through an API, but through an actual ROS message interface. Next there is the recognition that a renderer needs more of a function call interface rather than a publish/subscribe interface, so there is a function call like abstraction built on top of the pub/sub messages. It is a hassle to write all those pub/sub messages for function calls by hand, so there is an interface generator tool which outputs .msg files based on interface descriptions.

However, I think there are some good ideas we can take from RVE:

• Most of the code of rviz should be in libraries. The rviz application itself should be a small bit of code that just puts the right pieces together. This way people can easily include visualizations in their own programs.
• The property system (as seen by Display subclasses) should not be tied to a GUI toolkit. The property system is a pervasive element in rviz. Tying it to a specific GUI system like Qt or wxWidgets is a big impediment to future porting. Clearly a GUI toolkit needs to be connected to the property system, but it should be possible to use the property system without the GUI as well.

Backwards Compatibility

There is a lot of code that relies on RViz and we will have to deal with the currently poorly defined stable API of RViz. For example, there are some Python bindings that are used by someone else, and also a couple of existing external plugins. You will need to find out what other packages rely on the RViz API in one of those ways before you decide to make fundamental changes and break things.

A simple approach to this problem is to leave rviz unchanged and essentially copy it into a new package or packages, then do our major API changes there. Once "rviz2" is similarly capable to rviz, we can begin recommending that people migrate to the new system. We could leave the old rviz in place indefinitely for legacy users, for whom the change might be more painful than beneficial.

The big danger of the separate-code-base approach is that we will get part way finished with it (as with RVE) and need to stop working on it for some reason. Then the work on the new thing is lost completely.

A port to Qt almost needs this kind of separate code base approach because it can't be done half way and still have a usable system. Several plugins people have written use wxWidgets components to create new GUIs for interacting with their custom stuff. These will also be completely broken by the change.

Rendering Library

Is Ogre a dead end and you need to get away from it?

• Ogre seems to be a going concern still. The forums continue to have questions asked and answered, and new versions are still being released.
• Ogre is pretty complex, and the documentation is not that great.
• There are likely other better cleaner 3D rendering libraries out there, and porting to one of them might make future development easier.
• The port would take a lot of time, as Ogre is central to most of the rviz code.
• The possible benefit of making future display plugins easier to write could be achieved by writing some tutorials showing how to do it (with Ogre).

GUI Library

Is wxWidgets a dead end and you need to get away from it?

WxWidgets doesn't seem like a dead end per se, but it is not a popular choice of GUI library. The documentation is not great. For lack of a more specific complaint, it is not much fun to program with.

kwc: a specific complaint is that wx development is not nearly as active as Qt, which has led to major integration issues on OS X. wx was slow to react to OS X Snow Leopard and still has not produced a new release that is compatible with OS X. Instead, there is a development 2.9 binary that has to be downloaded directly from their website to get things compiled. In the meantime, it has taken less time for Apple to release a new OS update, than it has for wx to get a truly OSX compatible version. We originally chose wx because, 4 years ago, Qt was still reeling from its licensing issues. Since then, it has gone under very active development and cleaned up its licensing issues, while wx has basically stagnated. That said, Qt is now stuck under the threat of Nokia stagnation, but that, IMHO, makes it no worse in the future than wx.

Does it make sense to port to Qt?

Qt *is* fun to program with. The documentation is quite good. It is very popular.

What are the benefits and hazards?

If we both port to Qt *and* move most of the classes into libraries, we will enable a lot of people to write programs which use the libraries. Several projects at Willow involve GUIs written in Qt, and then there's rviz running in a separate window alongside.

How much work is it?

Interactive Markers

Do we need more control types?

Are there problems with the message interface?

Should we add a feature for enforcing limits within rviz?

Plugins

Current plugin API is undocumented, but a number of plugins are in use.

What is best route to a clean plugin API?

Do we need to change the plugin API?

Which plugin scheme to use? ROS's pluginlib? maybe Qt has one? Others?

Displays

Should we introduce more displays for other message types (e.g. surfels, gaussian ellipsoids, planes)?

Which are highest priority?

OSX

Should there be the option to build on OSX? How would a Qt port impact this?