| Description | Each proxy and property has a name and optionally a label. The name is what is (supposed to be) used problematically whereas the label is what shows up in the GUI. This has lead to confusion in Python scripting because the GUI labels did not match up the object names and fields, so the Python scripting now uses the labels (mangled into valid identifier). However, there are still issues of confusion when dealing with C++ code, which are further confounded by the fact that the name of the associated VTK class/method may also be different. There are also issues with ambiguity when proxies expose properties from other proxies. (Is the label exposed or just the name? What is an alias?)
Having widely different strings for the name and label is almost always bad, yet it is prevalent throughout the server manager code. Use programmers don't seem to be able to help ourselves, so perhaps the server manager should encourage doing the right thing. Some options are:
* Check that a name and the label are the same modulo superficial differences (like spacing). ParaView could emit a warning if it encounters such a change. Perhaps a way to override this could be created for extenuating circumstances.
* Do away with labels but allow names to be more expressive. Currently names have to be valid identifiers, but that does not seem to be necessary any more. Access within C++ is done through strings, so no reason not to have spaces and such there. For when an identifier is needed (such as for Python scripts), use the same mangling we are already doing for labels. To make transitioning easier (and to simplify the common request to change a GUI label to make more sense), perhaps there could be a list of other valid names for backward compatibility. |