Group configuration is not consistent

[cottsay]

Let me first describe the current group state behaviour:

1. When the dynamic_reconfigure client starts, states are initialized to the latest published states from ~/parameter_updates. The states included in the published states are initialized to those described in the .cfg file, so this behaviour is correct.
2. When the consumer of the client attempts to update the state, it sends a configuration to update only the group(s) it intends to change the state on. The client internally grabs all of the states from the ~/parameter_descriptions to start with, and then applies the difference. There are two problems here:
   • The ~/parameter_descriptions (should) hold the default state values, which may have changed since startup.
   • The ~/parameter_descriptions currently populates the default group states all with True instead of the default state specified in the .cfg file.
3. This results in all states being set to True, except the states which the consumer intended to change, which are set appropriately.

My question is this: Should the states behave the same as the other parameters, in that they start with their default and any time a client changes a state, the change is propagated to the other clients?

This could be a little awkward for a collapse group, which collapses and is hidden when the state changes to False. One client collapsing the group would automatically collapse it on another. It would be possible to not propagate the collapse group state changes to the parameter server, meaning that this behaviour would not emerge. Is this a good move?

I am perfectly happy writing and fixing code, I just want to know how which way to head...

Thanks,

--scott

[dirk-thomas]

From a MVC point of view I would classify the parameters and their value as being part of the model. But the state information about collapsed / not-collapsed groups is a view specific configuration. And multiple views should be able to maintain a separate configuration.

[cottsay]

Thanks for your input, @dirk-thomas.

I, then, propose the following:

1. Update "default" values to correctly reflect the "default" states for groups specified in the .cfg file
2. Update group state change behaviour to prevent the unintentional group state changes we're currently experiencing.
3. Update rqt_reconfigure to not send group state changes to the server, but allow the server to send group state changes to it (primarily so that hide groups function correctly. We still want the server to be able to enable and disable some groups).

Comments?

[dirk-thomas]

Sounds reasonable to me.