Using "sensor data" QoS profile with BEST_EFFORT

[karl-schulz]

Fixing #41

• Using sensor data QoS profile with BEST_EFFORT
• Tested locally with a BEST_EFFORT image publisher

[karl-schulz]

I don't think the build failure is related to this fix...

[jacobperron]

Looks good to me, thanks for the PR!
I've suggested one small change that, I think, would make rqt_image_view even more flexible.

[jacobperron]

I also don't think CI failing is a result of this PR. I suspect it is related to our transition to Ubuntu Jammy.

[wep21]

@jacobperron #66 and wodtko#1 (#68) fixes the ci failing.

[karl-schulz]

Looks good to me, thanks for the PR! I've suggested one small change that, I think, would make rqt_image_view even more flexible.

Cool, I did not know about these options.

[jacobperron]

I've rebased to get the latest fixes on rolling-devel.

[jacobperron]

The changes LGTM, but unfortunately ROS command-line arguments do not work because we're not parsing them:

https://github.com/ros-visualization/rqt/blob/5af2ce3877f8b6a95e0b60e479a310812bef7296/rqt_gui_cpp/src/rqt_gui_cpp/roscpp_plugin_provider.cpp#L90-L96

Until we start properly parsing CLI args in rqt_gui_cpp, we can't set ROS parameters at startup, like the QoS overrides...

[jacobperron]

I've filed a ticket upstream (ros-visualization/rqt#262) and disabled the feature (f61e7a7) to avoid misleading users that the exposed ROS parameters can actually be set.