See also ocornut/imgui#1651 - it isn't yet possible to recover from bad plugins.

It would be acceptable not to draw anything for one frame, remember that a particular plugin is bad, and not draw it the next frame.
But even determining which plugin is bad is maybe a problem.

Look at https://github.com/ros2/rviz for example of pluginlib in ros2, also https://github.com/ros/pluginlib/tree/bouncy

Made some changes in ocornut/imgui#1651 to facilitate error recovery in the most common cases (it doesn't include all the cases, merely some of the common ones, more to come..). The plugin/script language is expected to be able to recover from IM_ASSERT (which can be defined to your own function).

Note that you can easily destroy/recreate the imgui context while runinng (you may loose a little bit of state but it is bearable), which may be a useful technique in some cases of trying to recover from error (I don't have any specific idea in mind, just pointing out that it is easy to do).

I agree that determining which plugin is causing the issue isn't going to be trivial, but catching IM_ASSERT call can be useful there.

Look into IM_ASSERT above.

Don't need to get too deep into learning pluginlib, the class_loader macro and createInstance() takes care of it.

Want to have any rclcpp::Node to have generic status that can be drawn in a widget, and perhaps controls (once renaming, remapping, other options can be changed after construction). Not sure how easy to get access to interesting information in the node. NodeLoader would provide the list of all the loaded nodes.

There are higher level ways to get access to everything going on inside the current ros2 domain, whatever ros2 node list, ros2 topic list are doing, look at their code and make an imgui widget version.

NodeLoader needs a dedicated widget to show all the loaded nodes, and controls to remove them, and later a gui to spawn a new one with given options. Maybe a derived class of NodeLoader could provide that functionality.

Any given node either of my own or from other sources needs ability to have custom imgui control panel. Would have to match nodes as they are loaded to control panel functions? (and give those functions access to protected data?) Have a file full of plugins here to match to nodes from outside packages? (th

Additionally some nodes could be of a derived type that has imgui methods built in- would have to treat those differently, that seems easier but more limited to a smaller number of nodes that I create here.