<div dir="ltr">+1 on the project, I'm glad to see this getting attention!<div><br></div><div style>For the Qt version of rviz, I wrote a property hierarchy system in C++ which I have been fairly happy with.</div><div style>
<br></div><div style>For example usage, see map_display.cpp: <a href="https://github.com/ros-visualization/rviz/blob/groovy-devel/src/rviz/default_plugin/map_display.cpp">https://github.com/ros-visualization/rviz/blob/groovy-devel/src/rviz/default_plugin/map_display.cpp</a></div>
<div style><br></div><div style>That system uses Qt slots to receive notice of property changes when needed. (If Qt is undesirable you could probably go with Boost slots or even just member function pointers.)</div><div style>
<br></div><div style>The bit about rviz's property API that is perhaps unique is that the Property object actually owns the data.  That means any time you want one of the property values you say something like "width_property_->getInt()" or "name_property_->getString()".  What is returned by the Property object is always the latest value.  If you need to learn about updates, you don't need any parameters coming through the update function, because you can just ask the parameter object for the latest value from inside the update function.  This felt simpler to me than requiring API users to implement get/set functions for every parameter, which is how it had been implemented before.</div>
<div style><br></div><div style>Dave</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Apr 17, 2013 at 12:43 PM, Thibault Kruse <span dir="ltr"><<a href="mailto:kruset@in.tum.de" target="_blank">kruset@in.tum.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I found my draft rep, and now put it on github:<br>
<a href="https://github.com/tkruse/rep/blob/nodeparam/nodeparam-REP.rst" target="_blank">https://github.com/tkruse/rep/<u></u>blob/nodeparam/nodeparam-REP.<u></u>rst</a><br>
<br>
Note this was work in progress when I stopped working on it.<br>
<br>
Other things I considered back then:<br>
- whether to support complex parameter types like poses (rather than just primitive values)<br>
- how to organize parameter naming (I think there were some inconsistencies between rospy and roscpp around the '~')<br>
- using the same system for logger levels<br>
- grouping of parameters instead of having flat lists<br>
- whether to support batch updates of multiple parameters as one operation (e.g. when parameter validation would else deadlock changing two interdependent parameters)<br>
<br>
cheers,<br>
  Thibault<div class="HOEnZb"><div class="h5"><br>
______________________________<u></u>_________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org" target="_blank">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/<u></u>listinfo/ros-users</a><br>
</div></div></blockquote></div><br></div>